----- 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?
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?)
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.
Additionally, you should consider showing the vNIC name and not "eth0" etc.
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.
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).
4. I do not see ovirt-guest-agent mentioned in the feaure page. It is
the obvious channel to report that cloud-init is Done to Engine.
5. When we come to implement auto-generate of system ssh key, we may
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)
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.
7. Don't forget backwards compatibility considerations for the engine-VDSM
communication, if you're using APIs that aren't available in older VDSM versions.
Engine-devel mailing list