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

[Anthony Liguori <anthony@codemonkey.ws>]

On 10/22/2010 01:20 PM, Chris Wright wrote:
> * Anthony Liguori (anthony@codemonkey.ws) wrote:
>    
>> On 10/22/2010 12:29 PM, Chris Wright wrote:
>>      
>>> * Anthony Liguori (anthony@codemonkey.ws) 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?

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).

>    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.

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.

> 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.

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

Regards,

Anthony Liguori

> thanks,
> -chris
>