problem reading VMFS filesystem formatted on other ESX Server

[Hompie]

Hi,

We have two pools of ESX Servers, with their own SAN and VC.

To move some VM's over we attached an FC Based VMFS formatted in one of the pools via iSCSI on the another ESX Node in the other pool.

All systems are on the same patchlevel , esx 3.0.2 + VC 2.2.

The other ESX Server can see the LUN, it can see the size, and that nothing is free (the complete lun is VMFS formatted)

But despite several refreshes it doesn't see the VMFS, and it's contents. When testing a format it does warn that the LUN is in use, and will destory all data when formatting.

we basically want to copy from the original lun to a new lun on the new san by attaching that new lun to the old esx server via iSCSI.

, and then deregister on the orignal VC, and register on the new VC, and detach the lun from the old ESX server and make it only available to the new pool. We did reboots, refresh, rescan, doesn't help. Anyone have any tips?

Reason to do it this way is we need to copy a lot, and for the admins it's less challenging this way, using the VC, then doing this on SAN level.

[tommi00]

Look into the /var/log/vmware/hostd.log when doing the rescan.

It should reveal why the VMFS is not shown. I remember a setting in Advanced Settings -> LVM, DisallowSnapshotLun which was affecting the visibility of my LUN for data integrity reasons..

But that message shows up in the hostd.log

[GBromage]

I suspect tommi is on the right track with the Advanced Settings -> LVM, DisallowSnapshotLun option.

The SnapshotLUN option checks that the order that the LUNs are presented to the host is consistent with the LUN signature. The reason for this option is that, if you were using snapshot LUNs, you wouldn't want the ESX host to get confused as to which is the original LUN, and which is the copy.

If your LUNs are being presented in a different order on one of the hosts, this will be your problem. Changing the option and then doing a rescan should help.

Long term, you may want to look at the EnableLUNResigniture option to fix the numbering. But I don't know specifically how this option works, or if it poses some risk to your LUNs.

Hope that helps,

Greg

[Hompie]

The exact error message is:

Datastore xxxx has changed provider volume pointer

Looking at the settings to see if we can get it working,.

[Hompie]

Ok,

We tested it and this is what we found:

\- It is indeed a protection against overwriting.

=> LVM DisallowSnapshotLun will allow the VMFS under the original name to appear.

=> LVM Allow Signature set to on will ignore Disallowsnapshotlun setting, and will reattach under a new name. (snap_originalname) But only on the host wgere allowed.

So the best thing to do is activate Disallow, do a rescan, and then deactivate it again. but it needs to be done on all hosts.

Anyone have a better suggestion?

[Hompie]

Ok,

that seems to cause more problems then we want.

Will have to go through the resignaturing process again, looks like ESX can;t really handle it.