Re: [libvirt] [PATCH 3/6] Introduce yet another migration version in API.

Daniel, I looked at the patch-set you sent out on the 2/9/11 [libvirt] [PATCH 0/6] Introduce a new migration protocol to QEMU driver http://www.mail-archive.com/libvir-list@redhat.com/msg33223.html What is the status of this new migration protocol? Is there any pending issue blocking its integration? I would like to propose an RFC enhancement to the migration algorithm. Here is a quick summary of the proposal/idea. - finer control on migration result - possibility of specifying what features cannot fail their initialization on the dst host during migration. Migration should not succeed if any of them fails. - optional: each one of those features should be able to provide a deinit function to cleanup resources on the dst host if migration fails.

---------------------------------------------- enhancement: finer control on migration result ---------------------------------------------- There are different reasons why a VM may need (or be forced) to migrate. You can classify the types of the migrations also based on different semantics. For simplicity I'll classify them into two categories, based on how important it is for the VM to migrate as fast as possible: (1) It IS important In this case, whether the VM will not be able to (temporary) make use of certain resources (for example the network) on the dst host, is not that important, because the completion of the migration is considered higher priority. A possible scenario could be a server that must migrate ASAP because of a disaster/emergency. (2) It IS NOT important I can think of a VM whose applications/servers need a network connection in order to work properly. Loosing such network connectivity as a consequence of a migration would not be acceptable (or highly undesirable). Given the case (2) above, I have a comment about the Finish step, with regards to the port profile (VDP) codepath. The call to qemuMigrationVPAssociatePortProfile in qemuMigrationFinish can fail, but its result (success or failure) does not influence the result of the migration Finish step (it was already like this in migration V2). It is therefore possible for a VM to lose its network connectivity after a (successful) migration.

BTW, would the new functionality being discussed in this 3D "RFC: virInterface change transaction API" http://www.redhat.com/archives/libvir-list/2011-April/msg00499.html be able to provide the same configuration "atomicity" (ie, rollback in case of migration failure)? My understanding is that: - Such new framework would apply to (host) network config only. Even though it may cover the VDP (port profile) use case I mentioned above, it would not apply to other features that may need some kind of rollback after a migration failure.