Do I have to leave the 'DisallowSnapshotLUN' set at 0?

[storkit]

Scenario - We have 1 Compellent Storage Center serving 2 totally independent ESX 3.0.2 environments/clusters (Production and Non-Production). Every 1/4 we are going to copy the Production VMFS LUNS to create Test LUNS and then present them to the Non-Production ESX servers. I am aware and understand the concepts regarding the 'DisallowSnapshotLUN' and 'EnableResignature' switches. In our case and because the copied LUNS are being presented to a completely different set of ESX hosts we can use the DisallowSnapshotLUN and set it to 0.

That's all very simple but what if I want copy the Test volumes again to create a Develpoment environment also using the Non-Production ESX servers!!! Now we have to use the EnableResignature as the volumes are going to be presented to the same ESX hosts.

What I need to know is whether the DisallowSnapshotLUN setting has to be left off (0) for the Non-Production ESX hosts or can it be switched back on once an initial scan has been completed. If it does have to be left off I presume it needs to be switched off on all servers?

On top of this my concerns are as follows:

1. If the DisallowSnapshotLUN setting is left off (0) then we can't present the Development LUN copies to the Non-Production ESX hosts as the volumes are identicle?

so

2. If the DisallowSnapshotLUN setting can be turned back on (1) once I have presented the Test LUNS to the Non-production Hosts, I would then create the Development LUNS from the Test LUNS and set the EnableResignature. The Development LUNS would be presented OK but would it also reset the Test LUNS?

I appreciate there is a lot to take in above but can anyone help with this headache. I can see some testing needs to be done but any help is much appreciated!

[ponpalani2001]

Hi

Check this thread

http://communities.vmware.com/message/872606#872606

Thanks

[storkit]

Thanks. A good link but I already know the concepts described in the thread. What I'm trying to do goes beyond there comments as I want to use both settings if possible.

My biggest question is whether the DisallowSnapshot LUN has to be left off (0) all the time or just once for the first rescan as with the Resignature switch. In my mind I think it has to be left off (0) to work.

[abaum]

Bump

I am wondering the same thing. We are in the process of virtualizing our storage. One thing we found is that virtualization system is doing something that causes the ESX hosts to see the LUNs as snapshots. LUN IDs are the same so I don't know what's changing. Setting LVM.DisallowSnapshotLun to 0 fixes things. Do I have to keep this setting or is it a one time event (rescan and set it back to 1)?

adam

[storkit]

Hey Adam

Wow that could be a nightmare! I presume when you say Virtualising your storage you are using some kind of front end app covering a number of SANs?

I'm stacked for time but am looking to run a test. Can you do the same? Get an ESX server with no LUN's presented to it. Create a volume on the old SAN and present it to the ESX host.Virtualise that LUN and then play around with the DisallowSnapshotLUN'.

A headache but worth trying if we get no answers.

I have to be honest but I'm not entirely surprised the SAN virtualisation is doing it. They way I understand it, as soon as a Volume ID/signature changes (not the LUN ID) the VMFS ID will no longer match and ESX will think it is a snapshot volume. I would have thought the SAN Virtualisation software must be creating its own 'volume ID/signature' to differentiate all storage volumes in its own format.

BTW - Have you tried VMWare support?

Tom

[storkit]

To Add.....

You might have to do a planned disk resignature exercise but it could well involve re inventorying VM's and re-adding virtual disks if a vm has more than one.

[abaum]

According to our storage virt. vendor, there should be no changes that VM can detect. However, we have found a few items and they are going back to engineering. The product is supposed to leave all signatures/LUN IDs alone. The only reason I know the product is changing things is that when I look through all the host log files, I can see the disk discovery in the boot process and it shows up with my vendor's name.

Not so much a frontend app as a specialized firmware update for Cisco MDS. The MDS line allows for 3rd party plugins.

I've tried a few different test. I am currently running with default settings (LVM.DisallowSnapshotLun = 1) and it's working. I've rescanned a few times with no problems. The only thing I haven't done is reboot.

adam

[abaum]

That's exactly what I hoping to avoid. I have to many guests and custom settings (roles/security) that this is not an option.

adam

[opbz]

Very messy setup!

I have had to deal a lot with this snapshot issue. Once you have done your rescan you can ussually turn it off. But in your case I think you will have more problems. Basically you will ocnstantly have atleast 2 volumes that have exactly the same label.

Esx tends to deal with this by marking one or the other as snapshots. Now granted in your case you will have 2 luns with the same label so dissallowsnapshots and enable resignature should work. Now on a server by server basis this works.. a lot of the problem with this come from the Database in VC which keeps tabs of labels and luns

I expect this will get failry messy.. If I where doing this I would do this only on one server. Ensure things a resignatured and disallow snapshots on one one server only as you might end up with the lun being resignatured by one server then you power on the other server and it gets changed again..

I had issues where this has happened on systems where we had issues fixing the lun ids. basically meant I had to remove all hosts from VC to clear out its database and then re-add one at a time as otherwise you ended up with label mismatches from server to server...

not sure this will help but might clear up somethings..

[storkit]

Adam - I'd be interested to know how you get on after the reboot with the Disallowsnapshotlun switch now set to 1. Keep me posted!

opbz - You are right, always do this work on one server and then present to the others.

I'm also going to test disallowsnapshotlun being reset to 1 and a reboot ASAP - unless you get back to me in the meantime Adam. I still think the resignature method, although messy, is a much safer route in the long run (excluding DR environments) as it permanently guards against identicle volumes moving forward........

[abaum · Accepted solution]

Setting it back to 1 was not good. I had to set it back to 0 and rescan. So it appears that changing the setting does not update the disks themselves. Must cause ESX to ignore something instead.

adam

[storkit]

Fantastic (not for you maybe...I hope that didn't cause a major problem!)

In my head, that is what I expected it to do. Only Disk Resignature has the right to modify the VMFS ID.

You have saved me a trip into the office and points awarded accordingly!