Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format

[Kevin Wolf]

Am 29.07.2011 16:28, schrieb Anthony Liguori:
> On 07/29/2011 09:03 AM, Kevin Wolf wrote:
>> Am 26.07.2011 14:37, schrieb Anthony Liguori:
>>> Hrm, I'm not sure I agree with these conclusions.
>>>
>>> Management tools should do their best job to create two compatible
>>> device models.
>>>
>>> Given two compatible device models, there *may* be differences in the
>>> structure of the device models since we evolve things over time.  We may
>>> rename a field, change the type, etc.  To support this, we can use
>>> filters both on the destination and receive end to do our best to
>>> massage the device model into something compatible.
>>>
>>> But creating two creating compatible device models is not the job of the
>>> migration protocol.  It's the job of management tools.
>>
>> I'm not sure if I agree with this.
>>
>> Let's forget about management tools for a moment, and just think of a
>> qemu instance with a given set of command line option describing its
>> devices. Then you start another instance with different options and
>> -incoming and start a migration. The result will be something, but
>> definitely not a successfully migrated VM (even though it might look
>> like one at first).
>>
>> This is why I believe that the information about which devices to use
>> actually belongs into the migration data. There's no way to make use of
>> it with different options.
> 
> I agree with you actually.
> 
> Right now, it's the management tools job.  The complexity is daunting. 
> Recreating the same object model, particularly after hotplug, is 
> difficult and in many cases impossible.
> 
> I think the primary problem is that there are so many ways to create 
> things.  -M pc creates a bunch of stuff that there's no way to create 
> individually.  The stuff it creates can sort of be manipulated by using 
> -global but not on a per device basis.  Much of it isn't even addressable.
> 
> Creating backends is a totally different mechanism and each backend has 
> different mechanisms to enumerate and create.

And backends are actually something totally different: They are the part
that you can't migrate automatically, but that you must create on the
destination host like we're doing it today. The paths to images etc.
could be completely different from the source host.

The one change for backends is that if we migrate a device in way so
that it can say "I need the block backend with the ID 'foo'", then we
can at least make sure that the backend actually exists and is usable.

> The result is that introspecting what's there and recreating it is 
> insanely complex today.
> 
> That's the motivation behind QOM.  plug_list lists *everything*.  All 
> objects, whether they are created as part of the PIIX3 or whether it's a 
> backing file, can be directly addressed and manipulated.
> 
> If you look at qsh, there's an import command.  The export command is 
> trivial and I don't remember if I've already added it.  But the point is 
> that you should be able to 'qsh export' everything and then 'qsh import' 
> everything to create the exact same device model in another QEMU instance.
> 
> And yeah, this should end up becoming part of the migration protocol.

If all you're saying is that we can't get it tomorrow, that's fine for
me. Good to know that we agree on the goal anyway.

>>>>> 5) Once we're here, we can implement the next 5-year format.  That
>>>>> could be ASN.1 and be bidirectional or whatever makes the most sense.
>>>>> We could support 50 formats if we wanted to.  As long as the transport
>>>>> is distinct from the serialization and compat routines, it really
>>>>> doesn't matter.
>>>>
>>>> This means finishing the VMState support, once there, only thing needs
>>>> to change is "copy" the savevm, and change the "visitors" to whatever
>>>> else that we need/want.
>>>
>>> There's no need to "finish" VMState to convert to visitors.  It's just
>>> sed -e 's:qemu_put_be32:visit_type_int32:g'
>>
>> Actually I think the real question is whether we want to have VMState or
>> not.
> 
> VMState doesn't give me what I want by itself.
> 
> I want to be able to marshal the device tree to an in-memory 
> representation that can be manipulated.  One approach to doing that is 
> first completing VMState, and then writing something that can walk the 
> VMState descriptions.  The VMState descriptions are fairly complicated 
> but it's doable.
> 
> Another approach, which I'm arguing is much simpler, the imperative 
> nature of our current serialization and use visitors.
> 
> There may be other advantages of a declarative description of VMState 
> that would justify completing the conversions.  But I don't think we 
> need it to start improving the migration protocol.

Yeah, I somehow read it as "there's no reason to continue with
converting to VMState", which isn't what you were saying.

Kevin