Don't Read My Blog

Solaris 11.4 Shared Zone Storage Doesn’t Recognize The Same Mulitpathing Names that Solaris 11.3 Recognized

Solaris 11.4 Shared Zone Storage Doesn’t Recognize The Same Mulitpathing Names that Solaris 11.3 Recognized

Solaris 11.3 accepted shared devices that used the normal multi pathing names like /dev/dsk/c0t600C0FF0003B286921E7BD5B01000000d0 but Solaris 11.4 won’t recognize these as shared devices when you try to live migrate a zone:

root@zh3:~# zoneadm -z myzone migrate ssh://zh1
zoneadm: zone 'myzone': remote configuration check failed:
The storage property dev:/dev/dsk/c0t600C0FF0003B286921E7BD5B01000000d0 is not a shared storage URI.

You’ll need to convert these paths to use the luname format. This is described in the Oracle documentation, but here’s what you need to do.  NOTE you’ll need to reboot your kernel zone to make this change take affect, and you’ll have errors applying live changes to your zone until you reboot.

root@zh3:~# suriadm lookup-uri /dev/dsk/c0t600C0FF0003B286921E7BD5B01000000d0
dev:dsk/c0t600C0FF0003B286921E7BD5B01000000d0
lu:luname.naa.600c0ff0003b286921e7bd5b01000000
<further results excluded>

You’ll want to use the lu:luname.naa…

zonecfg:myzone> select device 0
zonecfg:myzone:device> set storage=lu:luname.naa.600c0ff0003b286921e7bd5b01000000
zonecfg:myzone:device> end
zonecfg:myzone> commit

As mentioned above, trying to live apply this change will cause an error because zoneadm apply tries to remove the device as part of the change, and the device is in use.  It’s possible that a live migration would make this change effective; I need to test that scenario (I did; keep reading).

Update:  I tested the live migration scenario, and the outcome is a bit interesting.  Here’s the steps I followed:

So first, I updated the zone using zonecfg to change its storage parameter to the lu:luname format.  I then live migrated from zh3 to zh1 with:

zoneadm -z myzone migrate ssh://zh1

At this point, the zone configuration, which did not exist on zh1, was created, but with the original /dev/rdsk/c0t… device names, not the lu:luname storage devices.  When I tried to migrate back to zh3, I received the is not a shared storage URI error again.  

At this point, I modified the zone config on zh1 to use the lu:luname devices, and then performed the live migration again.  Important to note is that the zone configuration already existed on zh3 using the lu:luname devices. At this point, the zone configuration on zh3 is now using the lu:luname devices, and I can run zoneadm apply

I suspect you could create the zone configuration ahead of time (with an export) on zh1 so that its configuration pre-existed with the lu:luname

Leave a Reply

Your email address will not be published. Required fields are marked *