Re: [Qemu-devel] KVM call minutes for Oct 19

[Chris Wright <chrisw@redhat.com>]

* Anthony Liguori (anthony@codemonkey.ws) wrote:
> On 10/22/2010 01:20 PM, Chris Wright wrote:
> >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?
> 
> No, but I'll waive my hands and say that I'm sure Windows has some
> appropriate mechanism to do the same thing (like PowerShell).

OK (bleh), but it's still specific to the guest OS.

> >   Really seems to
> >make more sense to have a stable ABI and negotiate version.
> 
> I guess the point is: we can always teach QEMU about how to work
> around older guests.  We (usually) can't control the software that's
> present on the guest itself.

I don't understand why we'd work around an older guest if the host <->
guest interface is stable.  Sure it can be extended, but old interfaces
should keep on Just Working (TM).

> The more logic we have in QEMU, the less we have to change the
> software in the guest which means the more likely things will work.

Maybe you're saying the advantage of injecting the raw commands into
the guest is that a host rev will automagically give an old guest new
functionality?

> >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.
> 
> This is the best (irrational) argument against this practice.
> Obviously, there's no real security concern here, but the end-user
> view may be troubling.

Heh, cloud + security == irrational fear, basic axiom

> That said, VMware has an interface for exactly this at least it's an
> established practice.

OK, what about other bits of API?  I recall seeing things like cut'n
paste, reboot, ballooning, time, few bits that spice would care about...
Are you thinking that as well, or all in terms of read/write/exec?

thanks,
-chris