openstack team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

On Sun, 1 Jan 2012, Ewan Mellor wrote:

> > -----Original Message-----
> > From: openstack-bounces+ewan.mellor=citrix.com@xxxxxxxxxxxxxxxxxxx
> > [mailto:openstack-bounces+ewan.mellor=citrix.com@xxxxxxxxxxxxxxxxxxx]
> > On Behalf Of Richard W.M. Jones
> > Sent: 21 December 2011 10:56
> > To: Scott Moser
> > Cc: openstack@xxxxxxxxxxxxxxxxxxx
> > Subject: Re: [Openstack] Metadata and File Injection
> >
> > On Thu, Dec 15, 2011 at 11:43:13AM -0500, Scott Moser wrote:
> > >  c.) No way to modify contents of the service after instance launch.
> > >      OK, I said 2 features, and really this one is wishlist.  If we
> > had an
> > >      arbitrary key-value store that was available, the user could
> > interact
> > >      with the guest using this service.  It'd have to be poll-based,
> > but a
> > >      in-guest hypervisor could watch for creation and deletion of
> > keys.
> > >      Potentially, the MD might be RW from inside guest, meaning it
> > could
> > >      even convey information back.
> >
> > Sounds like xenstore ...
>
> Yes, that's exactly what XenStore is.  Even better, you don't even have
> to poll -- it has an event system where you can block on a file
> descriptor until a subtree changes.  Oh, and it's a tree, not just a
> flat keyspace.
>
> Do you know, Rich, of any plans to implement something like XenStore for
> KVM?  OpenStack would have no problem abstracting the differences
> between two similar services, if there was something there to abstract
> over, but up until now people have pushed back hard on any feature that
> needed XenStore-like functionality, because it is completely missing
> from KVM.  I think that that's a shame, because there are lots of
> interesting things that you can do when you have a bidirectional, live
> channel into the guest.

within kvm/qemu, the path that is being worked to getting host-guest
communication outside of networking is being done via 'qemu-ga'.
http://wiki.qemu.org/Features/QAPI/GuestAgent

Thats a guest agent that would run inside.

It will communicate over a virtual serial (virtio-serial) bus with the
host.  The goal is to have full remote procedure call rather than just
key/value storage.

Its better to shoot for a full 2 way communication channel between host
and guest than to just settle for key/value.  The issue with key/value
would just be that you don't know if the other side received the message.

With the existing guest-file-{open,read,write} you can easily implement a
filesystem level tree like xenstore and use inotify from inside the guest
to monitor for changes.

I'm not suggesting that qemu-qa is either omnipresent nor acceptable at
the moment, but I generally agree with less hypervisor specific mechanism.
All that it really depends on is a 2 way communication channel between
host and guest.