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

[Anthony Liguori <anthony@codemonkey.ws>]

On 07/29/2011 10:18 AM, Kevin Wolf wrote:
> Am 29.07.2011 16:28, schrieb Anthony Liguori:
>
> 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.

Yup.  So with QOM, this could work in a couple ways.

You could dump the full graph including the backends, and then recreate 
it but not realize any objects.  This would give you a chance to make 
changes to things like the block device filenames.  It could be as 
simple as just changing the filename of a device, or deleting a complex 
block device chain (from backing files) and replacing it with something 
totally different.

I think the common case is that the backends are much the same so I 
think an interface centered around recreating the backends verbatim but 
allowing tweaks would probably be the friendliest.

We could also require that the backends are created before we migrate 
the device model.  In QOM, while you would be allowed to create a 
virtio-blk device, when you tried to set the drive property to 'foo', 
you'd get an error unless the 'foo' backend existed and was of the 
appropriate type.

Since it's pretty easy to enumerate the required backends, it's really 
not so bad for the management tools to do this work.  My only concern is 
that this all has to happen in the migration downtime window in order 
for hotplug to work robustly.

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

Yup :-)


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

No, not at all.  Just that converting everything to VMState isn't a 
prerequisite for building a more robust migration protocol.

Regards,

Anthony Liguori

> Kevin
>