Jagath, > -----Original Message----- > From: libvir-list-bounces@xxxxxxxxxx [mailto:libvir-list-bounces@xxxxxxxxxx] On Behalf Of Jagath > Weerasinghe > Sent: Friday, April 13, 2012 6:17 PM > To: libvir-list@xxxxxxxxxx > Subject: Re: VN-Link vNIC memory state copying on VM Migration > > Chris, > > Thanks for the reply. > > > what memory state do you refer to exactly? > What I meant by the memory state is the traffic being > transferred through the vNIC when VM migration is triggered. 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 > If this memory state (or traffic) is not copied and moved to the > destination vNIC how the smooth communication, which is > guaranteed on VM migration, is achieved? > > Thanks > Jagath > > > > > If you refer to port profile info, then there is no copying involved: > > the source host disassociates the vnic port profile and > > the destination host re-associates the port profile on the new vnic. > > > > /Chris > > > >> -----Original Message----- > >> From: libvir-list-bounces@xxxxxxxxxx > > [mailto:libvir-list-bounces@xxxxxxxxxx] On Behalf Of Jagath > >> Weerasinghe > >> Sent: Friday, April 13, 2012 9:16 AM > >> To: libvir-list@xxxxxxxxxx > >> Subject: VN-Link vNIC memory state copying on VM Migration > >> > >> Hi All, > >> > >> I am new to libvirt. And want to know how the VM migration > >> occurs in VN-Link (IEEE802.1Qbh). As far as I know, > >> the memory state of vNICs in M81KR VIC has to be copied > >> and moved to the destination vNIC on VM migration. > >> Is that correct? If so, could you please tell me how this > >> has been implemented in libvirt? > >> > >> Thanks > >> Jagath > >> > >> -- > >> libvir-list mailing list > >> libvir-list@xxxxxxxxxx > >> https://www.redhat.com/mailman/listinfo/libvir-list > > -- > libvir-list mailing list > libvir-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list