* Anthony Liguori (anthony@xxxxxxxxxxxxx) wrote: > On 10/22/2010 12:29 PM, Chris Wright wrote: > >* Anthony Liguori (anthony@xxxxxxxxxxxxx) wrote: > >>The first step is just identifying what interfaces we need in a > >>guest agent. So far, I think we can get away with a very small > >>number of interfaces (mainly read/write files, execute command). > >Could you elaborate here? I can't imagine you mean: > > > >vm_system(target_vm, "shutdown -r now") > > > >But from other post, it does seem you want complexity in the host side > >not guest side of agent. > > > >Seems vm_reboot(target_vm) as the RPC makes more sense with the guest > >side implementing that in whatever guest-specific appropriate way. > > What I really want is a vm_system API that a guest agent MUST > implement and then APIs like vm_reboot that a guest agent MAY > implement. > > In my mind, the guest agent lives in the distros even though it's > built from QEMU source tree. We don't install it ourselves. > > That means we might have a new funky fresh version of Fedora 21 > version of QEMU but running an old Fedora 14 guest with a really > back-level guest agent. > > Having very low level APIs with logic that primarily lives in QEMU > gives us the ability to support new features in QEMU with older > guests. I'm not sure about that. That same new shiny Fedora 21 QEMU has no idea what the right OS specific command to run in guest is. Granted, it's not likely that "reboot" or "shutdown -r now" are likely to change for Linux guests, do we assume cygwin for Windows guests? Really seems to make more sense to have a stable ABI and negotiate version. Also, from the point of view of a cloud where a VM agent is awfully close to provider having backdoor into VM...a freeform vm_system() doesn't seem like it'd be real popular. thanks, -chris -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
