On Sun, 1 Jan 2012, Ewan Mellor wrote: > > -----Original Message----- > > From: openstack-bounces+ewan.mellor=citrix....@lists.launchpad.net > > [mailto:openstack-bounces+ewan.mellor=citrix....@lists.launchpad.net] > > On Behalf Of Richard W.M. Jones > > Sent: 21 December 2011 10:56 > > To: Scott Moser > > Cc: openstack@lists.launchpad.net > > 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. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
