[libvirt] RFC: Migration with NPIV

[Osier Yang]

On 2012年11月20日 09:36, Zou, Yi wrote:
>> 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?

No, it doesn't have to match the WWNN of HBA.

Please look through the threads for the currrent agreement, it's much
different with this proposal.

Regards,
Osier