5:50 p.m.
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:
>>
>> http://www.ovirt.org/Features/Cloud-Init_Integration
>>
>> 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,
either.
These are things we can add--to both oVirt and cloud-init, I guess at a
later time.
> 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
non-relevant fields.
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
PCI address).
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.
It is
> 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
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)
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
engine-VDSM
communication, if you're using APIs that aren't available in older VDSM
versions.
Thanks, it does rely on some new vdsm API features.
>
> Dan.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>