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

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.