Hi Nicholas,
Ok, i'll likely have to end up reverting this to the old logic to avoid
this all together for -rc3, but I would really like to know the severity
of this first for the 'inactive umounted VMFS volume' case. I think
that forcing existing users to have to do this is not completely out of
the question when upgrading from out-of-tree -> mainline code, but we
need to ensure that VMFS is intelligent enough to recover from this in
the first place.
Well, in case of inactive volumes, VMFS resignature is a solution. But
the biggest problem is to make a volume inactive within a running
vCenter cluster environment. There is nothing like "unmount" GUI command
for normal datastore volumes. You can only delete them, which destroys
all data on them. I've put together the following sequence of steps
which seems to be a way to unpresent a volume from running vSphere
cluster, change NAA identifier in LIO and add the volume back to vSphere:
(1) In vSphere Client, stop and unregister _all_ virtual machines that
use the given volume.
(2) Using bloody vCLI magic, mask and unpresent the LUN from _all_ ESX
hosts. See VMware KB articles 1015084 and 1009449 on kb.vmware.com.
(3) Make sure that the LUN paths and datastore have disappeared from
vCenter inventory.
(4) Change NAA identifier of the volume on LIO side (LIO upgrade in our
case).
(5) Delete masking rules introduced in (2). See VMware KB 1015084.
(6) In vSphere Client, rescan storage adapters of all ESX hosts and make
sure that the LUN is visible and has a new NAA.
(7) Add the datastore back to vSphere inventory using "Add storage"
wizard. When adding the datastore, existing VMFS volume is identified
and you will be asked for VMFS mount option ... choose "Assign a new
signature".
(8) Datastore will be added with a name like
"snap-22d9ddbe-originalname". Rename it to "originalname".
(9) Using datastore browser, add the virtual machines unregistered in
(1) back to vCenter inventory.
(10) When powering-on a virtual machine, VMware complains about changed
uuid and asks you whether the machine was moved or copied ... choose "I
moved it."
After these steps, I was able to restart a virtual machine stored on the
given VMFS volume. Tested on two-node vCenter cluster with VMware
vSphere ESXi 4.1.
Finally, note that I'm quite sure that ESX 3.x works differently because
NAA-based signatures were introduced in vSphere 4.x, but I haven't
enaugh time and hardware to play with ESX 3.x too.
Martin
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
