Host: ESX 3.5 110268 attached to EMC SAN
Today I presented 5 new LUN's to the host, 3 R5 Metas and 2 SRDF+R1 Metas. All Metas are configured exactly the same (the R5 and R1 ones)
I was able to create VMFS3 volumes on three of them (2 R5 and 1 SRDF+R1).
On the remainig two I get a message that the partition table can't be read and I can't create a VMFS3 partition on them (via VIC 2.5).
I changed to the console and figured out which devices are these two (using esxcfg-vmhbadevs). It turned out that these are "/dev/sda" and "/dev/sdc".
I then tried to overwrite the MBR by using "dd if=/dev/zero of=/dev/sda bs=512 count=1".
Then I tried to create a VMFS3 partition with "fdisk" which works (at least I got no error message). To be sure I ran "partprobe". There I get the message "Error: Unable to satisfy all constraints on the partition." two times (I guess for the both devices).
A "fdisk -l /dev/sda" still returns that there are no valid partition tables on this device.
Still stuck with this.
Hello,
I would recreate the LUN. But it sounds like someone may have a lock on the LUN. I would check that as well. Check your storage devices log files as well as the vmkernel of the host on which you are creating this.
Best regards,
Edward L. Haletky
VMware Communities User Moderator
====
Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.
CIO Virtualization Blog: http://www.cio.com/blog/index/topic/168354
As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization
All LUN's (Meta) were created from scratch out of 16 and 24 Hypers, mapped to two frontend ports and masking was granted to all six ESX hosts. I presented them to a Windows host and even this one wasn't able to initialize the disk ("Internal Error" whatever that means).
I'll be back in the office next Wednesday. I'll recreate them and check the log files.
Nothing in the logs.
Recreating the device (Gone through the whole process again and presented the device to only one host via one path) didn't change the behaviour.
I opened a case with EMC.
EMC did a check and there were some Hypers within the Meta which had a reservation. They're going to delete the reservation. Interestingly they couldn't be seen via the Control Center.