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