On 07/31/2011 11:43 PM, Anthony Liguori wrote:
On 07/31/2011 05:48 AM, Dor Laor wrote:
On 07/30/2011 01:28 AM, Anthony Liguori wrote:
No, not at all. Just that converting everything to VMState isn't a
prerequisite for building a more robust migration protocol.
The main thing is to priorities the problems we're facing with.
- Live migration protocol:
- VMState conversion is not complete
But this is not a problem because it doesn't gate anything. That's my
point.
The VMState might be an exception but in general we have too many
unfinished businesses going on.
- Live migration is not flexible enough (even with subsections)
To make it more flexible, we need to be able to marshal to an internal
data structure that we can transform in more flexible ways.
- Simplify destination cmdline for machine creation
This needs qdev fixing.
- Qdev
- conversion is not complete
- Machine + devices description are complex and have hidden glue
This is a hard problem.
- Qapi
- Needs merging
We merged the first part (which includes the new QMP server). The work
is done for converting the actual QMP commands.
- QOB
- Only the beginning
So overall there are many parallel projects, probably more than the
above. The RightThink(tm) would be to pick the ones that we can converge
on and not try to handle all in parallel. There are problems we can live
with. Engineering wise it might not be a beauty but they can wait (for
instance dark magic to create the machines). There are some that prevent
adding new features or make the code hard to support w/o them.
Cheers,
Dor
ps: how hard is to finish the vmstate conversion? Can't we just assume
not converted code is not functional and just remove all of it?
No. VMState is a solution looking for a problem. Many important device
The initial target solved some rare bugs, that tend not to bite us with
virtio. On the way, it got enhanced with subsections that was a major
improvement.
models are still not converted and ultimately, it doesn't solve the
problem we're really trying to solve.
From the start I supported Michael Tisrkin's idea for ASN.1 protocol.
The question is how visitors and ability to translate from one
representation to another will help us. I do see value in it but I don't
think it is that important. If we have one real device serialization
method that is flexible enough we can stick with it w/o translation. If
we define qdev serialization into vmstate/asn.1/json/other and add some
capability negotiation and various other goodies it should be enough.
btw: separating the live migration protocol from the machine state is
even more important if we take a gradual approach.
Regards,
Anthony Liguori
Regards,
Anthony Liguori
