On 06/16/2013 05:08 PM, Mike Kolesnik wrote:
----- Original Message -----
> On Thu, Mar 28, 2013 at 07:35:23PM -0400, Greg Padgett wrote:
>> Hi Everyone,
>> I'd like to propose a feature we've been doing some investigation
>> into, which is to integrate cloud-init support into oVirt.
>> Cloud-init is used to help provision new Linux systems by setting
>> the hostname, ip, ssh keys, timezone, injecting files, and more.
>> It's used by OpenStack (amongst others) now, and has a lot of
>> features that may be helpful to our users.
>> Details are still evolving, but for more info please see the wiki page:
>> All feedback is welcome!
> All feedback? Even if it's 3 months too late?
I'll have to be more careful next time to specify a time limit :) But
really, thank you both for the comments. Feel free to add them to a "nice
to have" list on the wiki page, or I can add it. Replies inline...
> If so, then here's a few comments:
> 1. oVirt-3.2 completely supports IPv6 within guests. It would be nice to
> carry this on to cloud-init, by allowing to set the IPv6 address of
> the guest. (or are we happy with the auto configured ipv6 addresses?)
It would, but unfortunately cloud-init doesn't yet translate ipv6 fields
from /etc/network/interfaces (its chosen networking input format) to
ifcfg files. Now that you mention it, it doesn't add IPV6INIT=yes,
These are things we can add--to both oVirt and cloud-init, I guess at a
> 2. I think that the GUI used for setting IP addresses should be
> immitated here. It allows Static/DHCP/None, and disables the
> irrelvant fields when DHCP/None is selected.
It's close: there is a checkbox for dhcp, and if selected it will hide the
Additionally, you should consider showing the vNIC name and not
IIUC udev rules are rather unpredictable in this regard and could give your
vNIC a different name on different VM instances (probably by MAC address and/or
Either way, I think it's less confusing to refer to the vNIC itself.
Similarly to the above, I'm not sure how much cloud-init supports with
respect to vNICs. The name is used as the /etc/network/interfaces adapter
name and the ifcfg-* suffix (per distro), so I guess if you plumbed
everything around that in the image and could finish the setup with just
the interfaces/ifcfg config file then it would work as-is. If that isn't
adequate (I haven't looked or tested) then we may need to consider
submitting a patch to add this to cloud-init.
> 3. Is "Support custom volume label for vm payloads"
still on the TODO
> list? Note: F19's dosfstools has renamed mkfs.msdos to mkfs.fat.
> This means that creating a virtual floppy with a payload currently
> does not work there (it's a tiny fix, for sure).
It's implemented. Of course, it still uses mkfs.msdos.
> 4. I do not see ovirt-guest-agent mentioned in the feaure page.
> the obvious channel to report that cloud-init is Done to Engine.
You're right, and this is one part of the feature that hasn't been done.
It may also require some work on cloud-init, or for us to use a different
input format (i.e. a mime-formatted sequence instead of vanilla
config-drive-2). It would be great to add this, though my time to do that
now is a bit limited.
> 5. When we come to implement auto-generate of system ssh key, we
> want to install a virtio-rng device in our VMs, to ensure that the
> keys are not too easy to guess. (or create the key in the host and
> inject it to the guest)
Good idea. I'm not too familiar with virtio-rng, but if the image can be
configured to use it then the regeneration should follow suit. So, not a
limitation right now but not as easy as it could be. It's another case of
needing either a cloud-init patch for support or (I'm thinking more likely
in this case) some scripting and using a mime-formatted input to cloud-init.
6. Is this going to be supported on template/instance type level?
Probably static IP is not wise on a template, but the other options seem
like they would be the same for most VMs from the same template/instance.
Today it's just on "Run VM Once" but once we can persist the cloud-init
options I don't see why we wouldn't want to allow persisting at least at
least some of the fields for templates/instance types.
7. Don't forget backwards compatibility considerations for the
communication, if you're using APIs that aren't available in older VDSM
Thanks, it does rely on some new vdsm API features.
> Engine-devel mailing list