VMware Cloud Community
mikepodoherty
Expert
Expert
Jump to solution

EMC DMX COnfiguration Question

Had a problem where all the virtual guests locked up last night. Not sure if this was the problem but we recently converted several LUNS on a DMX 3 from supporting Windows servers to one LUN supporting VMWare. All the ESX servers saw the storage on both HBAs but there was one difference - all the servers saw SCSI ID 5 as vmhba1:5:8 vmhba1:5:8 629.85 GB 8; but for SCSI ID 4 and SCSI ID 6, there was a discrpency in that most saw the storage as

vmhba1:6:19 vmhba1:4:19 629.85 GB 19

vmhba1:4:19 vmhba1:4:19 629.85 GB 19

but a couple of the servers saw the LUNS as

vmhba1:4:19 vmhba1:5:19 629.85 GB 19

vmhba1:6:19 vmhba1:5:19 629.85 GB 19

I pointed the Storage configuration to SCSI ID 5. However, yesterday one server locked up and had to be rebooted. Upon reboot, multiple error messages related to vmhba1:4:19 appeared - vmhba1:4:19:1 may be snapshot: disabling access. See resignaturing section in SAN config guide.

This morning all the vmware servers locked up and had to be rebooted - all reported the vmhba1:4:19 error: vmhba1:4:19:1 may be snapshot: disabling access. See resignaturing section in SAN config guide.

I removed the storage pointing to vmhba1:5:8 and could reboot the servers without errors.

However, all the servers report the same configuration for SCSI ID 4, 5, and 6:

HBA 1

SCSI target 4

Path Canonical Path Capacity Lun ID

vmhba1:4:0 vmhba2:4:0 60 mb 0

vmhba1:4:19 vmhba1:4:19 629.85 GB 19

SCSI target 5

Path Canonical Path Capacity Lun ID

vmhba1:5:0 vmhba2:4:0 60 mb 0

vmhba1:5:8 vmhba1:5:8 629.85 GB 8

SCSI target 6

Path Canonical Path Capacity Lun ID

vmhba2:6:0 vmhba2:4:0 60 mb 0

vmhba1:6:19 vmhba1:4:19 629.85 GB 19

HBA 2

SCSI target 4

Path Canonical Path Capacity Lun ID

vmhba2:4:0 vmhba2:4:0 60 mb 0

SCSI target 5

Path Canonical Path Capacity Lun ID

vmhba2:5:0 vmhba2:4:0 60 mb 0

SCSI target 6

Path Canonical Path Capacity Lun ID

vmhba2:6:0 vmhba2:4:0 60 mb 0

I talked with our EMC engineer and he reports no problems. However, I am concerned that SCSI ID 5 doesn't see the same information and that all the HBA 2 information doesn't show the LUN.

Am I right to be concerned? Would resignaturing help? (Note: The fibre channel path is managed by a different agency - I've talked to them and they see no problems. However, getting the SAN guy, the fibre channel guy and the other organizations involved together for troubleshooting is a major headache.)

I should also point out that SCSI IDs 1-3 all point to a Dell Clarion with identical information and we've had no problems. SCSI ID 7 points to the same EMC DMX but there are no SCSI IDs 8 or 9 to compare configuration information. I am looking at the max LUN settings to see if there is an issue there as the SAN guy says the new LUN is configured identical to the 2 old LUNS on the DMX - which were configured at different times.

Thanks for your help

Mike O'D

Reply
0 Kudos
1 Solution

Accepted Solutions
admin
Immortal
Immortal
Jump to solution

Hello

At this point, I will refer you to EMC technical support... I'm not a DMX specialist but we get this similar issue and EMC give use this procedure who resolve the problem. This is a know issue for EMC.

View solution in original post

Reply
0 Kudos
6 Replies
admin
Immortal
Immortal
Jump to solution

Hello,

Is you partition have been aligned? See

Jeff

Reply
0 Kudos
mikepodoherty
Expert
Expert
Jump to solution

The Storage was added using the VI client which automatically alligns the partion.

The Storage was configured as vmfs3.

Reply
0 Kudos
admin
Immortal
Immortal
Jump to solution

Using fdisk on service console to align VMFS volumes

By default, ESX server will create VMFS that are misaligned

Execute the following steps to align VMFS

  • On service console, execute "fdisk /dev/sd<x>", where sd<x> is the device on which you would like to create the VMFS

  • Type "n" to create a new partition

  • Type "p" to create a primary partition

  • Type "1" to create partition #1

  • Select the defaults to use the complete disk

  • Type "x" to get into expert mode

  • Type "b" to specify the starting block for partitions

  • Type "1" to select partition #1

  • Type "128" to make partition #1 to align on 64KB boundary

  • Type "r" to return to main menu

  • Type "t" to change partition type

  • Type "1" to select partition 1

  • Type "fb" to set type to fb (VMFS volume)

  • Type "w" to write label and the partition information to disk

You are now ready to create VMFS on the partition.

Use MUI or vmkfstools to create the VMFS

Screen Shots of the procedure is shown in the next few slides.

The virtual disks on the VMFS will now be aligned.

However, guest OS will misalign IO's inside the virtual disk.

For Linux guest OS follow the procedure listed above

Procedures for Windows hosts is presented after service console screen shots.

dwight
Enthusiast
Enthusiast
Jump to solution

VMFS in 3.0 stores information about the Lun in the metadata of the vmfs filesystem. When it comes up, it recomputes the metadata and compares it to the metadata on the VMFS. If they have changed, it assumes it is seeing a SAN mirror of a VMFS volume that may or may not be current and disables the volume since it can't be sure. When it does this, it gives the error "may be snapshot: disabling access".

Changing the host type of the Lun would be something I expect would cause this issue.

If you think about what could happen if you did san based mirroring and presented say the original and mirrored copy of a vmfs with more than one extent it would be possible for ESX to try and build the VMFS volume with extents that contained both old and new data, resulting in a corrupt VMFS volume.

It sounds like it would be a good idea to have your SAN people read the appropriate sections of the SAN configuration guide as it specifies the correct configuration, including the host types for different array types and specific options for some arrays as well.

If you aren't using SAN based mirroring, you can enable resignaturing in the advanced settings to get access to the VMFS volume again. You might want to consider turning it back off once you can access the volume again.

RHCE, VCP

RHCE, VCP Blog: http://computing.dwighthubbard.info
admin
Immortal
Immortal
Jump to solution

Hello

At this point, I will refer you to EMC technical support... I'm not a DMX specialist but we get this similar issue and EMC give use this procedure who resolve the problem. This is a know issue for EMC.

Reply
0 Kudos
mikepodoherty
Expert
Expert
Jump to solution

Problem turned out to be the configuration on the EMC DMX. Worked with the SAN Engineer to fix.

Reply
0 Kudos