openstack team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

On Tue, 3 Jul 2012, John Garbutt wrote:

> This seemed to crop up quite a lot in different sessions at the Design summit. I am certainly interested in a standard way to inject information into VMs.
>
> What I think we need is a cross hypervisor two-way guest communication channel that is fairly transparent to the user of that VM (i.e. ideally not a network connection).
>
> If I understand things correctly, we currently have these setup ideas:
>
> *         Config Drive (not supported by XenAPI, but not a two way transport)
>
> *         Cloud-Init / Metadata service (depends on DHCP(?), and not a two-way transport)

cloud-init does not require dhcp.  It explicitly supports the passing of
network interface definitions into it in Ubuntu 12.04.  Ie, config-drive
with static networking passed in works as it should.

> But to set the password, we ideally want two way communication. We currently have these:
>
> *         XenAPI guest plugin (XenServer specific, uses XenStore, but two way, no networking assumed )
>
> *         Serial port (used by http://wiki.libvirt.org/page/Qemu_guest_agent but not supported on XenServer)
>
> I like the idea of building a common interface (maybe write out to a known file system location) for the above two hypervisor specific mechanisms. The agent should be able to pick which mechanism works. Then on top of that, we could write a common agent that can be shared for all the different hypervisors. You could also fallback to the metadata service and config drive when no two way communication is available.
>
> I would love this Guest Agent to be an OpenStack project that can then be up streamed into many Linux distribution cloud images.

The only thing I don't like about this is there is so very little need for
long-lived communication between the hypervisor and the guest.  I
personally think that cloud-init gets this right. Its goal is to do what
it needs to do and get out of the way.  It should provide enough to
bootstrap you to a more intelligent "management framework", such as
puppet, chef, juju.... there are literally dozens of these things that work
perfectly well without a hypervisor specific transport.  They're widely
available, work "right now", and don't care if they're running on bare
metal, xen, kvm, microsoft virtual server... They just assume that you can
connect to them via network, which is a really well defined and tested
thing.

Its 2012, do we really need to design for the case where IP is broken or
not available?

I'm not arguing that "guest agents" are not necessary, I'm arguing that
there is extremely little need for them to be hypervisor aware.

(yes, there is value in the host being able to request the guest to freeze
its filesystem after receiving a API "freeze" request.  However, even
*that* could happen over IP).

>
> Sadly, I don't have any time to work on this right now, but hopefully that will change in the near future.
>
> Cheers,
> John
>
> From: openstack-bounces+john.garbutt=eu.citrix.com@xxxxxxxxxxxxxxxxxxx [mailto:openstack-bounces+john.garbutt=eu.citrix.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Day, Phil
> Sent: 03 July 2012 3:07
> To: openstack@xxxxxxxxxxxxxxxxxxx (openstack@xxxxxxxxxxxxxxxxxxx) (openstack@xxxxxxxxxxxxxxxxxxx)
> Subject: [Openstack] Setting VM passwords when not running on Xen
>
> Hi Folks,
>
> Is anyone else looking at how to support images that need a password rather than an ssh key (windows) on hypervisors that don't support set_admin_password (e.g. libvirt) ?
>
> Thanks
> Phil
>