> -----Original Message----- > From: Jagath Weerasinghe [mailto:jagfoss@xxxxxxxxx] > Sent: Tuesday, April 17, 2012 8:19 AM > To: Christian Benvenuti (benve) > Cc: libvir-list@xxxxxxxxxx > Subject: Re: VN-Link vNIC memory state copying on VM Migration > > Chris > > >> OK. In phase 3, the RAM used by VM in source host is copied to the > >> destination. Then what about the memory state of vNIC's in the M81KR VIC. > >> Isn't there any memory for traffic passing through vNICs and also for > >> vNIC statistics? What I am talking about is copying of this memory to the > >> destination vNIC. > > > > No, that data (statistics, etc) are not copied to the dst host/vnic. > > However, you can find those statistics/counters on the switch (which are > > preserved across live migrations). > > OK. I think this operation is the same for both IEEE802.1qbh (VN-Link) > and IEEE802.1qbg. Is that correct? I assume so. > One more thing. Could you please tell me where the port profile > association/dissociation messages of libvirt are converted to > VIC protocol messages. Is this done by CNA it self? Yes, the NIC firmware takes care of it. /Chris > >> > (*) 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