On 09/25/2014 10:13 AM, Vinzenz Feenstra wrote:
On 09/25/2014 06:41 AM, Shawn Starr wrote:
> Hello everyone,
>
> I wonder if you can tell me how I can do this. I'm creating a VM image
> that
> needs to discover it's hostname, IP address information so I can
> configure
> /etc/sysconfig/network,
> /etc/sysconfig/network-scripts/ifcfg-[interface] and
> other things.
That sounds to me like a use case for cloud-init.
>
> If I know the oVirt/RHEV engine to connect to, I can get this information
> successfully.
>
> However, when creating a dummy 'gold' VM image and having oVirt clone
> it. I
> have no 'key' to tell me what engine to connect to, other than trying
> them all
> and hoping for best.
>
> I've written some code with the oVirt SDK that needs to know the URL:
>
> from ovirtsdk.api import API
> import platform
> import yaml
> import sys
>
> api = API(url="https://HOW_TO_DISCOVER_THIS/api",
> username="USER@internal",
> password="PASSWORD",
> insecure=True)
>
> ...
>
> Is there a way to know the engine to connect to when VM has booted up?
>
> I tried poking around ovirt/rhev-agent and noticed this:
>
> in /usr/share/rhev-agent/vdsAgentLogic.py:
> self.vio.write('host-name', { 'name' :
> self.dr.getMachineName() })
This is a pretty ancient version of the guest agent. Nevertheless the
machine name is retrieved from the system, there's no magic happening by
talking to the engine or anything like that. If the system does not have
a configured FQDN or hostname it will just simply get what the system
has set. That might be even 'localhost@localdomain'
>
> It *looks* like I could get the host name from what oVirt has
> configured w/o
> knowing the engine to connect to? But I cannot open /dev/virtio-
> ports/com.redhat.rhevm.vdsm (since rhev-agentd) has it opened 'too
> many files
> open' error.
>
> When using OpenNebula in past, they mounted a ISO CD image that
> contained the
> VM's metadata you could read in as configuration and having also used
> AWS EC2
> You can connect to localhost to the VM itself to get metadata to get
> this sort
> of information.
That's what cloudinit is doing. :-)
From my knowledge however there is no metadata available to be received
within the guest without using cloudinit.
cloud-init uses "metadata" approach. you can pass 'userdata' of your own
on top of what the engine generates.