Tag Archives: ESXi

The Case of VMware and the missing SCSI ID

6 Replies

When you’re setting up Oracle’s Automatic Storage Management feature (ASM), you have to ensure that the ‘raw’ devices that you have added to your server for ASM’s use are assigned the correct device names and usable permissions every time the server bounces.

In the dark days of Red Hat 3 and 4, we generally arranged for that to happen by creating raw device mappings -but that’s no longer supported on RH5 or RH6. Instead, you’re supposed to create new udev rules which do the job of declaring which devices exist and which permissions they should at every server boot.

And one of the first things you have to do to write a decent udev rule is to correctly identify the hard disks that exist: you can’t apply a permissions rule to something which you can’t uniquely identify in the first place, after all.

So when this happens, you have a bit of a problem:

That’s four SCSI hard disks, previously added to my VMware Workstation virtual machine and partitioned, resolutely failing to respond to the scsi_id command, which is what you’re supposed to use to get a unique ‘id string’ returned for a device. This happens when I use virtual machines built on VMware’s ESXi 4.1 server, too.

But, funnily enough, it doesn’t happen if you use VirtualBox as your virtualization platform:

Now, I’m not going to say this proves VirtualBox is better than VMware (because it’s not), but I am going to point out that, by default, all VMware virtual machines exhibit this behaviour, which will stop you dead in your tracks if you’re trying to build a virtual ASM or RAC machine. Without that ID string, you can’t identify your ASM disks uniquely -and that means you can’t get those disks correctly discovered by the operating system …and it’s downhill all the way after that.

Lucky, then, that this is all fixable with a modest bit of re-configuration!

If you were running ESXi 4.1, that bit of re-configuration consists of

  • shut down your virtual machine
  • right-click the VM’s entry in the left-hand panel and select Edit Settings
  • click the Options tab
  • Select the Advanced -> General item on the left and click the Configuration Parameters… button you then see displayed on the right
  • Click the Add Row button
  • Add disk.EnableUUID as the name of the new row, and the word TRUE as its value (don’t use quotation marks around either of these entries).
  • Click OK to make the new parameter addition ‘stick’.

You can then reboot your virtual machine.

Sadly, VMware Workstation has no interface like this that allows you to add this new configuration key to your VMs. Instead, you are reduced to having to do it yourself, by hand, using a text editor. It’s easy enough, however.

First, find the directory where the files representing your virtual machine are stored. One of them will be called the name of your VM, with an extension of .vmx. In my case, for example, the file is called sl6.vmx, because when I created my VM, I called it “SL6″. The file will be 3 or 4KB in size. Open it in the text editor of your choice and at the very end of the file, add this line:

disk.EnableUUID = "TRUE"

The quotation marks around the word “TRUE” here are important and must be typed. Now save the edited file and reboot your virtual machine. You should find that scsi_id is now capable of returning perfectly usable values:

As you can see from this screenshot, my VMware virtual machine is now displaying SCSI IDs for my hard disks just fine. The values being returned are quite different from those shown earlier in my VirtualBox VM, of course, because VMware and VirtualBox handle virtual disk identification quite differently. Whatever the specific values might be, though, the important point is to be able to see a value of any sort!

ESXi Hard Disk Boo-Boo… and fix!

1 Reply

Running ESXi 4.1 in freebie mode, I accidentally created an XP virtual machine with an 8GB hard disk (instead of the intended 80GB). Inevitably, I failed to notice this until after I’d spent the best part of a day upgrading the thing to Kingdom Come and configuring large amounts of software. Starting from scratch with a new VM and a correctly-sized disk was, then, out of the question. But how, then, do you increase the size of an existing virtual hard disk?

With great difficulty, in a nutshell!

If you Google around a bit, you’ll see various people suggesting you can get yourself into the host machine’s “Tech Support Console” and run the command vmkfstools -X 80G ./name-of-disk-file.vmdk. However, when I tried this, I was told that the relevant file was not a valid virtual disk file… so, end of experiment with that technique. (I believe you can get this error message if the virtual machine has snapshots. Also if the file is corrupt!)

Anyway, here’s what I ended up doing instead to resolve the issue (and it’s not exactly pretty!)

First, shut down the virtual machine if it’s not already. Then right-click and Edit Settings. Add a second hard drive, this time sized correctly. Once that’s added, reboot the virtual machine.

Next, from within the virtual machine, visit http://www.miray.de/download/sat.hdclone.html and download the zero-cost HD Clone utility for Windows (the .exe is fine, no need for the .zip). Run that and install the software. If necessary, reboot once more.

Third, run the HD Clone utility. Select the Cloning option, and allow it to detect the two hard disks. Follow the prompts to clone the small original disk to the larger new one. Let it do its stuff (it took about 7 minutes to clone an 8GB drive). When prompted, allow it to automatically resize the finished clone, and do whatever else it feels needs to be automatically adjusted.

When the clone is complete, shut down the virtual machine. Go back to the right-click-edit-settings option and assign the first hard drive (the original boot disk) to IDE controller 1:1 (it started off on 0:0, which is what made it the first -and boot- hard disk). This frees up the 0:0 location for the second, larger hard disk you’ve just created, so now you click that and assign it to the just-freed-up 0:0 IDE interface (making it the new boot disk). Lastly, you click the original hard disk and click the Remove button (if you’re not feeling brave, select the option to remove the disk from the virtual machine without deleting the files off the physical host!).

This little game of deckchair shuffling means the new, larger hard disk ends up occupying the same position in the IDE chain of command as the original, smaller, one did. So when you now power on the virtual machine, it should correctly boot from the new hard disk. Windows XP certainly did, first time of asking -and then promptly went into that ‘new hardware has been detected, you must reboot for it to work properly’ routine. One further reboot later, therefore, and I finally ended up with an XP machine running on an 80GB virtual hard disk rather than an 8GB one.

I have read that you might need to jiggle the boot flags on the new hard disk, but I didn’t have to. If you do, you’ll have to alter the VM so that its CD/DVD Drive is pointing to an ISO of Gparted. That will let you set the new hard disk to be bootable, and then you should be good to go. Happily for me, HD Clone seems to take care of this by itself, so as I say, I never had to do this further bit of fiddling.

If all has gone well, you can use the ESXi Browse Datastore option to remove the physical file associated with the original virtual hard disk if you weren’t brave enough to physically delete it originally. You can also uninstall HD Clone from within the virtual machine, since you won’t (presumably) be needing it again. HD Clone works fine in Windows 7, by the way, so the same basic technique should apply to any vaguely-recent version of Windows, not just XP.