[libvirt-users] Ang: Ang: Re: Ang: Ang: Re: Ang: Re: attaching storage pool error

Hi! Report from my multipath tests today. My test virtual machine, that runs from an NPIV pool, is not able to use multipath. When I pulled the cable from one of the targets, it crashed. But, strangely, it could boot up again on that other path, that it just crashed on. That tells me it can use both paths, and is not limited to one of them only, but because the multipath layer isn't there, it can not survive a path failure, but can come up again on a reboot. The question is, WHY doesn't an NPIV pool support multipath? It is sort of the idea behind FC to be redundant and to always have multiple paths to failover to. Why was the NPIV pool designed like this? If we could use the underlying devices and pass them directly to the guest, then we could implement multipath in the guest. But I sort of lean to that not use the NPIV anymore, since it only seems to complicate things. In VmWare they can attach the NPIV directly to the guest, which means that the NPIV, and whith that the LUN's are easily transfered across the SAN hosts. Here, with libvirt/qemu/kvm, we can not attach an NPIV to the guest, which sort of makes the whole idea fall. Especially if this is the case, that there is no multipath support. Better then to map the LUN's directly to the host, and use the multipath devices for the guests. If anyone else has opinions on this, or ideas that are better than mine, I would very much like to hear them. Regards Johan -----libvirt-users-bounces(a)redhat.com skrev: ----- Till: John Ferlan <jferlan(a)redhat.com&gt; Från: Johan Kragsterman Sänt av: libvirt-users-bounces(a)redhat.com Datum: 2016-09-03 08:36 Kopia: libvirt-users(a)redhat.com, Yuan Dan <dyuan(a)redhat.com&gt; Ärende: [libvirt-users] Ang: Re: Ang: Ang: Re: Ang: Re: attaching storage pool error Hi, John, and thank you! This was a very thorough and welcome response, I was wondering where all the storage guys were... I will get back to you with more details later, specifically about multipath, since this needs to be investigated thoroughly. I have, with trial and error method, during the elapsed time, been able to attach the NPIV pool LUN to a virtio-scsi controller, and it seems it already uses multipath, when I look at the volumes in the host. It seems for me a little bit confusing with this multipath pool procedure, since an NPIV vhba by nature always is multipath. I will do a very simple test later today, the best test there is: Just pulling a cable, first from one of the FC targets, and put it back again, and then do the same with the other one. This will give me the answer if it runs on multipath or not. The considerations I got was, whether I would implement multipath on the guest or on the host, and I don't know which I would prefer. Simplicity is always to prefer, so if it is working fine on the host, I guess I'd prefer that. Get back to you later... /Johan -----John Ferlan <jferlan(a)redhat.com&gt; skrev: ----- Till: Johan Kragsterman <johan.kragsterman(a)capvert.se&gt;, Yuan Dan <dyuan(a)redhat.com&gt; Från: John Ferlan <jferlan(a)redhat.com&gt; Datum: 2016-09-02 20:51 Kopia: libvirt-users(a)redhat.com Ärende: Re: [libvirt-users] Ang: Ang: Re: Ang: Re: attaching storage pool error On 08/24/2016 06:31 AM, Johan Kragsterman wrote: I saw this last week while I was at KVM Forum, but just haven't had the time until now to start thinking about this stuff again ... as you point out with your questions and replies - NPIV/vHBA is tricky and complicated... I always have try to "clear the decks" of anything else before trying to page how this all works back into the frontal cortex. Once done, I quickly do a page flush. It was also a bit confusing with respect to how the responses have been threaded - so I just took the most recent one and started there. The Red Hat documentation is most up-to-date - it was sourced (more or less) from: http://wiki.libvirt.org/page/NPIV_in_libvirt There's some old stuff in there and probably needs a cleanse to provide all the "supported" options. This is an 'iscsi' pool format, but something similar can be crafted for the 'scsi' pool used for fc_host devices. So for the purposes of taking the right steps, I assume you used 'virsh nodedev-list --cap vports' in order to find FC capable scsi_host#'s. Then you created your vHBA based on the FC capable fc_host, using XML such as:    <device>      <parent>scsi_hostN</parent>      <capability type='scsi_host'>        <capability type='fc_host'>        </capability>      </capability>    </device> where scsi_hostN and 'N' in particular is the FC capable fc_host Then creation of the node device : #virsh nodedev-create vhba.xml Node device scsi_hostM created from vhba.xml where 'M' is whatever the next available scsi_host# is on your host. If you 'virsh nodedev-dumpxml scsi_hostM' you'll see the wwnn/wwpn details. You can then create a vHBA scsi pool from that in order to ensure the persistence of the vHBA.  Although it's not required - the vHBA scsi pool just allows you to provide a source pool and volume by unit # for your guest rather than having to edit guests between host reboots or other such conditions which cause The "volume" and "disk" or "volume" and "lun" syntax can be used somewhat interchangeably. As your point out the features for disk and lun are slightly different.  Usage of the 'lun' syntax allows addition of the attribute "sgio='unfiltered'" Let's forget about iscsi Works on my test guest (ok not the order from dumpxml): ...     <controller type='scsi' index='0' model='virtio-scsi'>       <alias name='scsi0'/>       <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>     </controller> ...     <disk type='volume' device='lun'>       <driver name='qemu' type='raw'/>       <source pool='vhbapool_host3' volume='unit:0:4:0'/>       <backingStore/>       <target dev='sda' bus='scsi'/>       <shareable/>       <alias name='scsi0-0-0-0'/>       <address type='drive' controller='0' bus='0' target='0' unit='0'/>     </disk> ... See above...  The controller has a "type", "index", and "model"... Then when adding the disk, use the type='drive' controller='#', where # is the index number from your virtio-scsi controller. You can use 'virsh pool-refresh $poolname' - it will find new luns... Err, it *should* find new luns ;-)  Existing 'unit:#:#:#' values shouldn't change - they should be "tied to" the same wwnn.  Use "virsh vol-list $poolname" to see the Path. So when new ones are added they are given new unit number's.  Reboots should find the same order. Fair warning, use of sgio='unfiltered' does require some specific kernels... There were many "issues" with this - mostly related to kernel support. If not supported by the kernel, you are advised : error: Requested operation is not valid: unpriv_sgio is not supported by this kernel Uhh... multipath... Not my strong suit... I'm taking an example from a bz that you won't be able to read because it's marked private. Once you have your vHBA and scsi_hostM for that vHBA on the host you can use 'lsscsi' (you may have to yum/dnf install it - it's a very useful tool)... # lsscsi ... //assume scsi_host6 is the new vHBA created as follow [6:0:0:0]    disk    IBM      1726-4xx  FAStT  0617  - [6:0:1:0]    disk    IBM      1726-4xx  FAStT  0617  - [6:0:2:0]    disk    IBM      1726-4xx  FAStT  0617  /dev/sdf [6:0:3:0]    disk    IBM      1726-4xx  FAStT  0617  /dev/sdg You'll need an mpath pool: # virsh pool-dumpxml mpath <pool type='mpath'>   <name>mpath</name>   <source>   </source>   <target>     <path>/dev/mapper</path>     <permissions>       <mode>0755</mode>       <owner>-1</owner>       <group>-1</group>     </permissions>   </target> </pool> # virsh pool-define mpath # virsh pool-start mpath # virsh vol-list mpath Name                 Path ----------------------------------------- dm-0                 /dev/mapper/3600a0b80005adb0b0000ab2d4cae9254 dm-5                 /dev/mapper/3600a0b80005ad1d700002dde4fa32ca8 <=== this one is from vhba scsi_host6 Then using something like:     <disk type='block' device='lun' sgio='unfiltered'>       <driver name='qemu' type='raw'/>       <source dev='/dev/mapper/3600a0b80005ad1d700002dde4fa32ca8'/>       <target dev='sda' bus='scsi'/>       <alias name='scsi0-0-0-0'/>       <address type='drive' controller='0' bus='0' target='0' unit='0'/>     </disk> HTH, John (FWIW: I'm not sure how the leap of faith was taken that dm-5 is the vHBA for scsi_host6... Although I think it's from the wwnn for a volume in the vHBA as seen when using a virsh vol-list from a pool created using the vHBA within the bz). _______________________________________________ libvirt-users mailing list libvirt-users(a)redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users