Re: [libvirt] VN-Link vNIC memory state copying on VM Migration

Jagath, Since you are worried about the traffic I assume we are talking about _live_ migration. Libvirt qemu migration V3 takes place in 5 phases. (If you search the mailing list archive for "migration v3" you will find a number of 3Ds) This is a simplified description of the algorithm: +--+ |VM| +--------+ +---------+ |Src host| |dst host | +--------+ +---------+ Phase1: BEGIN - Get XML of VM and tx it to dst Phase2: PREPARE - create (paused) VM based on XML Phase3: PERFORM - Copy RAM to dst - Pause VM .................................................. Phase4: FINISH - Apply port profiles .................................................. - Start VM Phase5: CONFIRM - Kill VM Libvirt on the dst host orchestrates everything using RPCs. Dst host can return error/success codes (the two libvirt also exchange data, .. see cookies) During phases 1/2/3 the VM is still running on the src host and hence able to rx/tx traffic. At the end of Phase 3, when qemu is done copying the RAM from source host to destination host (*), qemu puts the VM in pause state on the source host. (*) See the migration parameter 'migrate-setmaxdowntime' In phase 4 libvirt applies the port profile to the interfaces that need it and starts the VM (which had been created and put in pause state in phase 2). There is therefore a small period during which both VMs (the one on the source host and the one on the destination host) are in pause state (see dotted lines above). Phase 4 will start the VM on the dst host, Phase 5 will kill the (paused) VM on the src host. The amount of time during which both VMs are in pause state depends on a number of factors, including: - maxdowntime: the smaller you configure this value and - the longer will take the migration to complete, but - the smaller the pause duration will be - bandwidth available on the interface/s used to carry the migration traffic, and amount of RAM assigned to the VM (since you need to copy it) - time taken to complete the port profile associations on the dst host (which depends on how loaded the switches are) - ... Hope this clarifies a bit. /Chris