On 10/25/2013 04:27 AM, Peter Lieven wrote: > Ok, one way direction - i forgot about this paradigm. > > 2 thoughts: > > a) a send-capabilities capability that "stores" the capabilities that where > used when savevm was used. I would implement a special segment > right at the beginning of the data stream that has all capabilities listed > that > where set and that ultimately must be supported to import a saved state > under any circumstances. capabilities that are only have a meaning at > the source VM should not be set. if there is an unsupported capability > set the import can be aborted right at the beginning.
Sounds reasonable; but ideally, it would either have to be in such a way that doesn't break back-compat with older qemu, or else you have invented a new file format; and once you invent a new file format, we might as well make the file format sane by being FULLY self-describing (see also Alexander Graf's work from KVM forum on adding a migrate-debug device). That is, don't just require the same capabilities, but also require all other command line arguments to be sane in comparison to what the savevm image was using. > > b) an extension the the qmp-migrate-capabilities or a new command that give > the controlling process (e.g. libvirt) a hint which features are a good thing > to turn on > if they are supported on both sides (e.g. zero-blocks in block-migration). Not really needed. New capabilities must be off by default (back-compat reasons), so the only time they will be turned on at the source is if the management (such as libvirt) is smart enough to know what the capability does; once you can assume that, you can also assume the management knows how to set up the destination properly. Which is why what we have already works (making management do all the negotiation correctly). Yes, maybe qemu could make it easier or more foolproof, but since management already has to handle the job (particularly because management might be dealing with older qemu that doesn't have the ease-of-use additions), I'm not sure the effort of extra code in qemu is worth the effort. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
