Having freed up two 500GB SATA disks from my storage server, I wanted to put them in the ESXi server. Although my original intention for this box was to have an essentially disk-less system (USB key boot of the hypervisor only), the reality is that I've not got enough bays in the storage server and don't want to waste two perfectly good disks.
I've also got a little project in the back of my mind that could make use of these disks...
I put the disks in the server and booted ESXi. Using the VI client, I noticed that the disks were recognised, but when I went to add storage, I could select the disk
"Error during the configuration of the host: failed to get disk paritition information"
I booted off the CentOS disk and selected "linux rescue" and destroyed the partition table using fdisk. I wrote these changes and confidently rebooted.
I got the same error.
From the ESXi menu, I viewed the configuration logs and messages and noticed it was reporting the following:
Warning: /dev/sda contains GPT signatures, indicating that it has a GPT table. However, it does not have a valid fake msdos partition table, as it should. Perhaps it was corrupted - possibly by a program that doesn't understand GPT partition tables. Or perhaps you deleted the GPT table, and are now using an msdos partition table. Is this a GPT partition table?
I wasn't aware of what a GPT signature is/was, but it was obviously something that fdisk didn't overwrite. Some googling later suggested the problem could be solved by completely overwriting the start of the disk.
Back into the Linux rescue mode and some dd action (sledgehammer approach perhaps...):
# dd if=/dev/zero of=/dev/sda bs=1M count=1
Rebooted again and this time the disk is selectable and I could add the datastore. Repeated for the second disk and now I've got an additional 1TB of storage for VMs (albeit unmirrored, but that's fine in this non-production environment).
For those unfamiliar with dd, it's a fairly low level command that can copy raw data. The if= specifies the input file, the of= specifies the output file. In the above example, /dev/zero is a special Unix "file" that returns zero when read, and /dev/sda is the disk device I'm writing to. The bs= specifies the size of the block (1M = 1 megabyte) and count= specifies the number of blocks to read. So the above reads 1 block of 1MB size from /dev/zero (effectively 1MB of the "0" character) and writes this out to the disk, starting from the very beginning and overwriting everything there (which includes the partition table).
And this is why an understanding of Unix/Linux can be very useful, even if you don't do Unix stuff in your day job... :-)
4 comments:
Thank you VERY much for this. I had used two days trying to figure out what was wrong with my setup. After doing the dd-thing it worked. Thanks for sharing this with me and others.
My disk was brand new, but i had it put into a windoze machine before i got it attached to my ESXi. And maybe that was the mistake, cause W probably added a signature to it, that is visible nowhere.
Kristian in Denmark
Thanks for the encouraging feedback Kristian. Glad you got your problem sorted.
Yay! I've wasted hours pulling a drive from our iSCSI, shoving it in a desktop and slapping it about with gparted. (The drive had been part of a RAID set, and is now spare, so I'm using it for some eval.) Eventually I got an idle server to mount it in the iSCSI enclosure and reset the partition tables again and again, checking it time and again with ESXi.
One sweep with dd and it works like a dream. Wish I'd thought of it! Saved me beating my head through the monitor...
Thanks! Found this about the middle of my troubles and put it off because esxi4 doesn't include a dd util. Finally gave up all the gparted/vmkfstools garbage and unleashed some quality dd action on it. Works beautifully!
Now to make up the 4 wasted hours...
Post a Comment