Re: [libvirt] [PATCH/RFC] Introduce VIR_MIGRATE_FORCE flag to allow for risky migration
On 10/24/2011 02:00 AM, Daniel P. Berrange wrote:
On Fri, Oct 21, 2011 at 08:16:24PM +0200, Guido Günther wrote:
> Hi,
> Migration will be disallowed when the vm uses host devices or has
> snapshots (qemuMigrationIsAllowed)[1]. Would it make sense to introduce
> a VIR_MIGRATE_FORCE similar to VIR_REVERT_FORCE here? We could then
> introduce error codes similar to the snapshot case
> (VIR_ERR_MIGRATE_RISKY).
I'm not sure this will actually work out in practice because QEMU
itself also checks some of these scenarios and blocks them. So even
if libvirt didn't check, the user still wouldnt' be able to force
it to migrate.
That's true for hostdev passthrough (qemu refuses that, because you
don't have the same hostdevs on the destination), but not so for
snapshots (where right now, the only reason we don't permit it is due to
a lack of implementation in libvirt - it has no bearing on qemu).
Regarding the scenario of snapshot metadata, the biggest problem is that
v3 cookies are not large enough to send the description of each snapshot
in one rpc call. I've been thinking about that some more; it may be
possible to use migrate v3 to send the migration after all, by adding
the following to the cookies:
in Begin, an fdstream is opened, then cookie includes details about the
fdstream identifier. Then that fdstream is used to send a count of the
total number of snapshots, followed by a length of each snapshot then
the xml for that snapshot. Thus, the cookie is used to set up a second
channel between source and destination, where that channel has a defined
format for passing an arbitrary amount of data needed to reconstruct the
snapshot hierarchy on the destination. I don't know if the fdstream can
be run in parallel with the rest of the migration, or if it should be
completed prior to the rest of the Prepare steps; at any rate,
coordinating overall success or any failures on receiving the fdstream
will have to be communicated from the destination back to the source in
another cookie.
But if we can teach migration v3 to send snapshots, then it might mean
that we don't need VIR_MIGRATE_FORCE after all; the only place where
snapshots would prevent migration is when either side of the equation
doesn't know the new cookie, but those are the same situations where a
new flag would not be recognized to have any effect. Besides, you can
still manage snapshot migration manually, (albiet painfully), via a
series of snapshot-dumpxml on the source, then snapshot-create
--redefine on the destination.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org