[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: Live migration protocol, device features, ABIs and othe

From: Michael S. Tsirkin
Subject: [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts
Date: Tue, 24 Nov 2009 16:01:44 +0200
User-agent: Mutt/1.5.19 (2009-01-05)

On Tue, Nov 24, 2009 at 12:39:50PM +0200, Dor Laor wrote:
> On 11/23/2009 02:15 PM, Juan Quintela wrote:
>> Dor Laor<address@hidden>  wrote:
>>> >  In the last couple of days we discovered some issues regarding stable
>>> >  ABI and the robustness of the live migration protocol. Let's just jump
>>> >  right into it, ordered by complexity:
>>> >
>>> >  1. Control*every*  feature exposed to the guest by qemu cmdline:
>>> >
>>> >      While thinking on cross version migration, and reviewing some
>>> >      patches, I noticed that there are many times that we use feature bits
>>> >      in order to expose functionality for the guest driver - example:
>>> >      VIRTIO_BLK_F_BARRIER, but we do not control it from qemu cmdline.
>> In my opinion this is madness, qemu command line is already too
>> complicated.  I agree with anthony to put it in the command line.
> Qemu's cmdline is currently our config file.. Actually there is nothing  
> wrong with it. Human users shouldn't be interested with these changes  
> and management software should not have problem manipulating it.
> We do need flexibility of controlling our features like any other  
> software component.
>> I will go further, and think that this kind of issues should be put into
>> the machine type.
>> If you start qemu with -M pc-0.10, it should save the state in a 0.10
>> compatible way (that don't happens at the moment, but it should work
>> that way).
> That's the idea - to keep it part of qdev and by default use it with -M.

I think we want to keep these things separate:
machine description should be for things that
are both guest visible and not changeable by guest,
so it absolutely must stay constant as long as guest
it alive.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]