Re: [libvirt] RFC: Migration with NPIV

> On 2012年11月19日 17:30, Osier Yang wrote: >> Hi, >> >> This proposal is trying to figure out a solution for migration >> of domain which uses LUN behind vHBA as disk device (QEMU >> emulated disk only at this stage). And other related NPIV >> improvements which are not related with migration. I'm not >> luck to get a environment to test if the thoughts are workable, >> but I'd like see if guys have good idea/suggestions earlier. Glad to see this topic on the list. >> >> 1) Persistent vHBA support >> >> This is the useful stuff missed for long time. Assuming >> that one created a vHBA, did masking/zoning, everything works >> as expected. However, after a system rebooting, everything is >> just lost. If the user wants to get things back, he has to >> find out the preivous WWNN& WWPN, and create the vHBA again. >> >> On the other hand, Persistent vHBA support is actually required >> for domain which uses LUN behind a vHBA. Othewise the domain >> could fail to start after a system rebooting. >> >> To support the persistent vHBA, new APIs like virNodeDeviceDefineXML, >> virNodeDeviceUndefine is required. Also it's useful to introduce >> "autostart" for vHBA, so that the vHBA could be started automatically >> after system rebooting. >> >> Proposed APIs: >> >> virNodeDevicePtr >> virNodeDeviceDefineXML(virConnectPtr conn, >> const char *xml, >> unsigned int flags); >> >> int >> virNodeDeviceUndefine(virConnectPtr conn, >> virNodeDevicePtr dev, >> unsigned int flags); >> >> int >> virNodeDeviceSetAutostart(virNodeDevicePtr dev, >> int autostart, >> unsigned int flags); >> >> int >> virNodeDeviceGetAutostart(virNodeDevicePtr dev, >> int *autostart, >> unsigned int flags); > > One API missed is: > > int > virNodeDeviceCreate(virNodeDevicePtr dev, > unsigned int flags); > > To create the vHBA. > >> >> 2) Associate vHBA with domain XML >> >> There are two ways to attach a LUN to a domain: as an QEMU emulated >> device; or passthrough. Since passthrough a LUN is not supported in >> libvirt yet, let's focus on the emulated LUN at this stage. >> >> New attributes "wwnn" and "wwpn" are introduced to indicate the >> LUN behind the vHBA. E.g. >> >> <disk type='block' device='disk'> >> <driver name='qemu' type='raw'/> >> <source wwnn="2001001b32a9da4e" wwpn="2101001b32a90004"/> >> <target dev='vda' bus='virtio'/> >> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> >> </disk> >> >> Before the domain starting, we have to check if there is LUN >> assigned to the vHBA, error out if not. >> >> Using the stable path of LUN also works, e.g. >> >> <source dev="/dev/disk/by-path/pci-0000\:00\:07.0-scsi-0\:0\:0\:0"/> >> >> But the disadvantage is the user have to figure out the stable >> path himself; And we have to do checking of every stable path to >> see if it's behind a vHBA in migration "Begin" stage. Or an new >> XML tag for element "source" to indicate that it's behind a vHBA? >> such as: >> >> <source dev="disk-by-path" model="vport"/> >> >> 3) Migration with vHBA >> >> One possible solution for migration with vHBA is to use one pair >> of WWNN& WWPN on source host, one is using for domain, one is >> reserved for migration purpose. It requires the storage admin maps >> the same LUN to the two vHBAs when doing the masking and zoning. Is WWNN part of the migration? I mean, isn't WWNN normally associated w/ the underlying real vendor HBA and to have that also means the target of your migration has to match up that WWNN?