VMware Communities: Message List - ESX 3.0.1 and HP EVA 4000 LUNs

Re: ESX 3.0.1 and HP EVA 4000 LUNs

wobbler — Fri, 14 Mar 2008 08:41:33 GMT

In EVA 4100/6100/8100 there is a "feature" called select lun under the presentation phase.

unpresent the LUN from any host that has this problem, under presentation for the virtual disk highlight the host and press "select LUN" then make sure you assign the same id the rest of the host see this as.

and then rescan.

Re: ESX 3.0.1 and HP EVA 4000 LUNs

yairmg — Thu, 28 Jun 2007 15:11:25 GMT

Hi Vliegenmepper

the VM ( which "resides" in that lun ) is down , still can't rename the snap back .

any more ideas

thanks

Re: ESX 3.0.1 and HP EVA 4000 LUNs

Vliegenmepper — Mon, 29 Jan 2007 09:49:59 GMT

I believe that the reason why you can't rename to VOL01 lies in the fact that VOL01 is still somewhere mentioned in the database.
Can you check is VOL01 resides next to the snap-000002-VOL01? (press ctrl-shift-d in VC)

If so, check how many hosts, templates and VM's are connected and disconnect them. When all items are disconnected the VOL01 disappears from VC database and you are able to rename the snap-000002-VOL01 back.

Let me know if this works. I'm working with an EVA4K en EVA5K in the testing environment so I can simulate certain situations.

Re: ESX 3.0.1 and HP EVA 4000 LUNs

jpratt_at_norwich_dot_edu — Sat, 27 Jan 2007 14:42:48 GMT

I've had issues on eva5000/vcs3028 where i had to actually delete the virtual host's command view eva configuration/port settings, then recreate it when creating/presenting luns on esx 3.0.1, so that a server could "see" a new/shared lun properly - also note you must zone your san so that both/whatever servers that are sharing luns are in the same zone in your san fabric. (Especially if you have hosts on your san running different os'es!!)

regards,
jp

Re: ESX 3.0.1 and HP EVA 4000 LUNs

erik.1 — Thu, 30 Nov 2006 14:19:36 GMT

I have the same problem with one ESX 3.0.1 and a EVA6000

1. Unpresented the LUN (id 1) from ESX (name: VOL1)> rescan/refresh
2. Present same LUN with new id of 255 > rescan/refresh
3. LUN is seen, but no volume is seen
4. Changed EnableSignature to 1 > Rescan/refresh
5. LUN is seen and volume is seen as snap-00000002-VOL01

But now i cannot rename it back to VOL01

6. Set EnableSignature back to 0 (default value) > Rescan/refresh

But still no way to rename it back to VOL01

Re: ESX 3.0.1 and HP EVA 4000 LUNs

snowmizer — Tue, 14 Nov 2006 18:39:06 GMT

But when I resignatured my LUN it appeared as a snap on that ESX Server. From what I've read here and seen the snaps cause problems. If a volume shows as a snap how do I fix it so it's not a snap anymore? For VMs you can use the snapshot manager but it doesn't show when the LUN is a snapshot.

Re: ESX 3.0.1 and HP EVA 4000 LUNs

paulo.meireles — Tue, 14 Nov 2006 17:35:03 GMT

Whenever we create a VMFS the signature includes the LUN

ok, how do you make the volume available again if you have to change to LUN address for some reason?

That's precisely what resignaturing is for...
Just be sure to un-present the LUN from all hosts, rescan the SAN, present it to one host with the new LUN ID, rescan the SAN, resignature it, and then present it to the other hosts. Oh, and rescan the SAN.

Paulo

Re: ESX 3.0.1 and HP EVA 4000 LUNs

BUGCHK — Tue, 14 Nov 2006 14:46:38 GMT

You need to have your storage present the volume with the same LUN ID

That is no problem with the EVA - unless that particular LUN address is already mapped to a different virtual disk, but then the user got confused, not the EVA.

Whenever we create a VMFS the signature includes the LUN

ok, how do you make the volume available again if you have to change to LUN address for some reason?

Re: ESX 3.0.1 and HP EVA 4000 LUNs

donbaek — Mon, 13 Nov 2006 10:34:54 GMT

You cannot represent the LUN's with different LUN ID's. Whenever we create a VMFS the signature includes the LUN and if we see that same VMFS on a different LUN somewhere we must assume it is a snapshot.

Please note that the fix is NOT to resignature as that simply moves your problem. If two servers A and B can see the LUN and it has a VMFS formatted by host A, if B was to resignature the VMFS (because it saw it on a different LUN ID) then A would see this change at some point and believe that it now sees a snapshot.

You need to have your storage present the volume with the same LUN ID to all ESX servers sharing (or seeing) the LUN.

/Thor

Re: ESX 3.0.1 and HP EVA 4000 LUNs

vmmeup — Fri, 10 Nov 2006 20:42:44 GMT

I don't believe that those are snapshots. Those are most likely to be your actual vm's. Vmware is labeling the volume as a snapshot volume because it recognizes the vmfs partition, but something is different. It assumes you took a san snapshot of the lun and presented it. You should be able to rename the datastore to something other then snapshot* to whatever you like and boot the vm's.

Re: ESX 3.0.1 and HP EVA 4000 LUNs

snowmizer — Thu, 09 Nov 2006 21:30:43 GMT

Already tried checking the EVA, unpresenting the LUNs, rescanning. When I look at the results of my scan (under the Storage Adapter screen) I see a LUN that matches Vol01 but this doesn't show up on my Storage screen. I looked at the EVA to make sure the LUNs weren't presented to the server and found that Vol01 and Vol01 didn't have any presentations.

How do I get rid of the phantom entry that is showing up? Actually if I look at the volume that shows as a snap I see that my VM appear to have snapshots (that don't appear in the snapshot manager). I think I need to get this resolved before I can try representing the LUNS with different LUN IDs.

Re: ESX 3.0.1 and HP EVA 4000 LUNs

vmmeup — Thu, 09 Nov 2006 21:03:55 GMT

Are all the luns presented to all the servers as the same luns id?
Were any of the luns ID's previously used for an old lun?

I would go into command view eva and check all the lun presentations and make sure each lun is presented to each server and the same lun ID. If everything looks ok I would unpresent the luns from all the server. Then run a rescan on the servers to verify they no longer have them showing up. After that re present the luns but use a different lun ID making sure they are the same for all boxes.

Then run a rescan and see if your servers pick them up.

If they do not retry the command from my last post.

Re: ESX 3.0.1 and HP EVA 4000 LUNs

snowmizer — Thu, 09 Nov 2006 20:06:46 GMT

Ok, so now I am missing LUNs. I have two volumes (Vol01 and Vol02) created and presented to a test ESX server. When I run rescan I only see one (Vol02) in the Storage list even though the rescan of my storage adapters shows both volumes. If I look at the /vmfs/volumes list I see one of my volumes (Vol02) but if I do an "ls" on that volume it tells me that the file or directory does not exist.

I have tried unpresenting these LUNS and representing them but nothing changes.

I had been messing with presenting a LUN to multiple server before this problem happened. When I present Vol01 to another server and run the rescan my drive shows up as a "snap...". Is this what's causing my issue?

How do I fix this? Since these are test drives is my only option to delete the two LUNs and recreate them (as well as the VMs that are on them)?

Thanks.

Re: ESX 3.0.1 and HP EVA 4000 LUNs

vmmeup — Mon, 06 Nov 2006 21:49:21 GMT

do this.......

echo 1 > /proc/vmware/config/LVM/EnableResignature

vmware-cmd -V

First line enables resignature and the second does a rescan. Do on one server and then do a normal rescan on any other esx servers

Re: ESX 3.0.1 and HP EVA 4000 LUNs

paulo.meireles — Sat, 04 Nov 2006 16:03:53 GMT

On server X the LUN ID is 1. I would like to present the LUN to server Y. When I present the LUN to server Y the LUN ID is 5.

Whenever possible, each LUN should keep the same ID when presented to several VMware servers, especially if those are to be connected to the same VirtualCenter.

Paulo

Re: ESX 3.0.1 and HP EVA 4000 LUNs

b.silva — Sat, 04 Nov 2006 13:56:30 GMT

I had the same problem, I have it working now with:

LVM.EnableResignature=0, LVM.DisallowSnapshotLUN=0

I had the following entries on /var/log/vmkernel:
--------------------
Oct 19 13:05:23 vermontd02 vmkernel: 0:01:53:47.260 cpu0:1032)LVM: 5739: Device vmhba1:0:1:1 is a snapshot:
Oct 19 13:05:23 vermontd02 vmkernel: 0:01:53:47.261 cpu0:1032)ALERT: LVM: 4903: vmhba1:0:1:1 may be snapshot: disabling access. See resignaturing section in SAN config guide
---------------------
I believe that newer versions of the EVA software do not have this problem: the one we have now does not have the option to set the LUN client operating system as "vmware", the EVA admin had to create these LUNS as "linux" or something similar... I believe it is related, but I don't know much about SANs yet...

We are about to upgrade the EVA; I will update this post if the upgrade corrects this...

ESX 3.0.1 and HP EVA 4000 LUNs

snowmizer — Fri, 03 Nov 2006 15:51:25 GMT

I have a LUN created on my EVA 4000. It already has a vmfs file system set up as well as some vmdk files from a VM. On server X the LUN ID is 1. I would like to present the LUN to server Y. When I present the LUN to server Y the LUN ID is 5. I try rescanning the storage adapters on my server Y but the LUN doesn't show up.

I read pgs. 108-109 on the SAN config guide and have set the LVM.EnableResignature value to 1 (LVM.DisallowSnapshotLUN = 1). When I rescan my storage adapters on server Y my disk appears as "snap...". Am I correct that this means I have a snapshot of my LUN? If this is a snapshot then what are the implications of this? What do I need to do to get these LUNS to present correctly? Am I correct that I need to represent my LUNs to the ESX servers that will share them in the same order?

Thanks.