- Posts: 2
- Liked: never
- Joined: Oct 28, 2014 12:23 pm
- Full Name: IT BWZ Rapperswil-Jona
i get from emc Support a hlu conflict on the emc vnx (see emc kb000041822 on https://emc--c.na5.visual.force.com/ape ... 0000000EIe).
So the Support Team from emc mean, that we dont must fix the case because the veeam backup and recovery software does only communicate with the vcenter and not directly with the hlu and so he doesn't interested the hlu configuration.
Is this correct or did we must fix the hlu conflict?
Audience: Level 30 = Customers Article Type: Break Fix
Last Published: Tue Sep 30 09:10:32 GMT 2014 Validation Status: Final Approved
Summary: ESX Servers can get SCSI reservation conflicts if the Array LUNs are in multiple Storage Groups and the Host LUN ID (HLU) is inconsistent.
Impact How to make sure a LUN's Device ID or HLU Number is the same in multiple Storage Groups?
Troubleshooting LUNs that are present in more than one Storage Group.
Sharing LUNs between VMware and physical servers.
Issue A LUN that is in multiple Storage Groups does not have matching HLU (Host Device ID) entries.
Some VMware servers will probably be able to see the LUNs, but others may report SCSI reservation conflicts.
LUN's device number in the host CxTxDx value is not the same on different hosts, which are members of different Storage Groups.
Multiple hosts in the same Storage Group all have access to the same LUNs. All hosts must have the same Host LUN designation and each host must have the same preferred path (the Default SP Owner) to each LUN.
Environment Application SW: VMware ESX
Product: CLARiiON AX Series
Product: AX4 Series
Product: CLARiiON CX3 Series
Product: CLARiiON CX4 Series
Product: VNX Series
Product: VNX with MCx Series
EMC SW: Access Logix
EMC SW: Unisphere
Cause When you add LUNs into a Storage Group, the Host ID field will be blank. This field will dictate the Host Logical Unit number (HLU) of that LUN, which will be the Device ID of that LUN, as seen by any hosts in that group. If you do not click this and changes are applied, it will default to the next available value. Clicking the host ID space will present a drop-down box that can be used to select the required HLU.
Change This is a typical procedure for clustering Virtual Machines (for example, VMware) to physical servers.
Resolution Shut down any servers that use the Storage Group that will be changed because removing a LUN from the group will make it unavailable. If a LUN is in multiple Storage Groups and the HLU does not match, this can be fixed by removing it from one group, and adding it again, with a HLU that matches the other group (assuming that this HLU is available). Once all the necessary changes are made to the Storage Groups, the hosts must be booted again and the LUNs should be detected on their new IDs.
For more information about this issue, please see the following articles from VMware:
http://kb.vmware.com/kb/6482648 VMFS Volume Can Be Erroneously Recognized as a Snapshot
http://kb.vmware.com/kb/1016210 Virtual Disk 'X' is a mapped direct access LUN that is not accessible
http://kb.vmware.com/kb/1016222 Cannot see some or all storage devices in VMware vCenter Server or VirtualCenter
Notes Warning! If a LUN is placed in more than one Storage Group, all servers in those Storage Groups must be in a cluster configuration, or have some other method of preventing data corruption on the LUNs (which would happen if more than one server is writing to a LUN).
- Veeam Software
- Posts: 6026
- Liked: 1834 times
- Joined: Jul 26, 2009 3:39 pm
- Full Name: Luca Dell'Oca
- Location: Varese, Italy
sorry but I do not understand the issue, also the mentioned KB is password protected so only EMC customers can open it.
If I understand correctly, there's a mismatch in the LUN numbering between hosts? not sure how it does involves Veeam since, if the topic is DirectSAN backups, we only read the existing LUN as any ESXi server would do.
Indeed we connect to vCenter, retrieve the informations about the LUN and then connect via our DirectSAN proxy to read data from it.
Principal EMEA Cloud Architect @ Veeam Software
vExpert 2011 -> 2021
Veeam VMCE #1