Hi, all
This is a rough thought about how to allow the user to associate
a LUN as disk with WWNN/WWPN. Never mind if some thought
is complete wrong, I'm complete new to this area. :-)
The initial idea was to introduce new XML for the vHBA which the
LUN which be assisned to in a domain XML, just like comment #2
of RHBZ# 543037:
<quote>
AFAIU libvirt needs a way to:
- Associate a virtual adapter WWN with a VM (in the VM xml)
- Learn to start a virtual adapter when the VM is started, and destroy the
adapter when the VM is stopped.
- Possibly a way to associate a WWN with a scsi pool, to start / stop a
virtual adapter with the pool.
</quote>
But afer thinking more, I'd think it might be not good idea:
As far as I could understand, the requirement of the BZ wants
a way to create/migrate a guest with NPIV. I'm goint to talk
create first,and migration then.
=== Creation
If we try to support this all inside libvirt, it means we need to
new XML for indicates the WWNN/WWPN of the vHBA or Physical HBA,
this is fine we can do it, though it's a bit annoyed where to add
it. The biggest problem is there is a race here, we can't known
the path of the LUN unless the storage admin assigned (zone / mask,
will already use assign for brevity) a LUN to the (v)HBA, and it
appears on host successfully. However, domain define/create doesn't
allow the disk source path be empty, except it's CDROM, or Floppy.
The works which need to be done before domain define should
be:
- If the user wants to create new vHBA.
1) auto-generate /or specify WWNN/WWPN (with Qumranet's OUI: 00-1A-4A)
2) allows to select fabric WWN, (to guide the choice of which FC
adapter to select for the Vport creation, assuming different
adapters connect to different fabrics)
3) create the vHBA with virNodeDeviceCreateXML API
4) Ask / prompt the user to ask the storage admin assigns the LUN
to the vHBA.
5) Waits for the LUN shows up on host (perhaps via storage pool
API)
6) Use the LUN's path (e.g.
/dev/disk/by-id/scsi-3600c0ff000d7a2a5d163ff4490100000000-part1)
as the disk source path.
- If the user wants to select a existed (v)HBA.
1), 2) and 3) are ommited
3) and 4) might be also ommited if there is a LUN already assigned
to the selected (v)HBA.
As we can see, there are lots of interaction. If we simply wants
to do all these work inside libvirt, we lose the user friendly
interaction, and just makes our life harder.
So, I would these work should be done in external / upper apps,
e.g. virt-manager, or Boxes in future. What libvirt needs to
do (as far as I could get):
1) support the fabric WWN in node device XML
2) may be we can do auto-generating the WWNN/WWPN inside libvirt
if they are not specified. But from a user's p.o.v, I'd see it
is in UI, but not in codes silently.
3) perhaps provides methods to get the (v)HBA's fabric's WWN?
=== Migration
If we do things as explained above for domain's creation, the disk
XML will be like:
<disk type='disk' device='disk'>
<driver name='qemu' type='raw'/>
<source
file='/dev/disk/by-id/scsi-3600c0ff000d7a2a5d163ff4490100000000-part1/'>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03
function='0x0'/>
</disk>
It's just similiar with disk which uses a normal disk image. So we needs
to something to indentify it's special, it's a LUN assigned to a (v)HBA.
Ways to do that in my mind are:
1) If we could find the WWNN/WWPN/fabricwwn by the LUN's path, (I'm not
sure if there is a good way yet), things will be much simpler, what
we need might be just a simple flag to tell the disk source path is
LUN assigned to (v)HBA. e.g.
<source file='$path_of_lun' type='fc_hba'/>
2) if there is no way to get the WWNN/WWPN/fabricwwn by LUN's path, we
might need the whole config of (v)HBA. e.g.
<souce protocol='fc' file='$path_of_lun'>
<hba>
<wwnn>$wwnn</wwnn>
<wwpn>$wwpn</wwpn>
<fabricwwn>$fabricwwn</fabricwwn>
</hba>
</source>
And then in virt-manager or Boxes, it needs to detect if there is disk
use FC LUN, if it's it should teach dest libvirt to create another vHBA,
and assign the same LUN to it. Then migration could do just as normal.
But problem of doing like so is the migration won't work anyway with
virsh.
Hmmm, /me thinking if it will be disireable to introduce hook support
for migration. Things will be much simpler if we support hooks?
Thoughts and Opinions?
Regards,
Osier
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list