You’re familiar, of course with Windows software mirroring: A poor man’s RAID.

In the traditional hardware world, you added two disks, loaded Windows on one of them, added the second one as a mirror set, optionally added a line in the boot.ini with the second ARC path, and you were off to the races.

ESXi has a fairly specific list of RAID controllers that it is fully compatible with, and sometimes either you don’t have one to work with, or the one you have doesn’t work right. In such cases, if you want fault tolerance, you have to get creative about.

This, then is a creative plan:

1. Establishing Software Mirroring in ESXi (or Hyper-V, for that matter)
2. Add one physical disk to your server.
3. Install ESXi on the disk.
4. Disconnect the disk.
5. Connect a second disk.
6. Install ESXi on the second disk.
7. Connect both disks and boot. Verify that ESXi can see both datastores.
8. Create your VM, and add two virtual hard disks of identical size to it. One virtual disk should be placed in each datastore.
9. Load Windows, and add the second virtual disk as a mirror set.

It’s quite simple, really, and it’s the same concept – the only differences are that you have to load your base OS (ESXi) twice, and that if you have a failure on your primary boot disk, you’re going to have to create your VM (using the existing virtual hard disk) on the second OS on order to boot it. That’s not such a big deal, really. A bit of a manual process, but not bad.

Fair warning: Switching back and forth between ESXi instances in this configuration had some interesting and undesirable results in the area of snapshots, and virtual disk files, so your best bet is to do this only when you have to becauseof disk failure. If you have an active snapshot when your primary disk fails, you’re going to forcibly be reverted to the snapshot. It could get very interesting. I recommend very short-lived snapshots in this scenario.

Come to think of it, I don’t really recommend this scenario – but if you’re broke/desperate, or don’t have much to lose…

Tags: ESXi, Hyper-V, RAID, Software Mirroring

A customer was kind enough to let me play mad scientist with one of his servers today, and I learned the following:

The HP Proliant DL320 G3 is (mostly) compatible with ESXi.

What I mean by “mostly” is that while ESXi will recognize and use the hard disks, it doesn’t really like the ICH6R RAID controller.

• When you disable the RAID controller in the BIOS, and put two disks in the server, ESXi will see two disks.
• When you enable the RAID controller, and create a RAID1 mirror from two disks, ESXi will see two disks.
• If you load ESXi on one of the two disks it see when when they are mirrored, it will fail to boot.

So, your best bet is to turn off RAID, and use software mirroring if you want fault tolerance.

ESXi will detect and use the network interfaces (HP NC7782).

This server is 32-bit so your OS options are limited.

I also discovered by experimentation that this server will recognize a 1TB SATA disk, so that’s useful.

Tags: compatibility, ESXi, Proliant DL320 G3

Who the heck runs Windows XP on ESXi anyway? I suppose someone with an excess of Windows XP licenses who doesn’t want to buy TS CALs might do it. Someone with RDP-enabled thin clients might do it as well.

Anyway, I was about to kill the XP workstation VM I used to test my trial run of the SBS 2003 to SBS 2008 migration, and decided to try out this ASR thing. I ran a backup, including ASR. I stored the BKF file on a remote workstation share, and stored the ASR file on a virtual floppy.

Then I created a new VM with appropriate disk, ram, and CPU settings, and attached the virtual floppy image to it. I also inserted the VMware SCSI drivers for Bus Logic into that virtual floppy image. Next, I attached a Windows XP ISO image to the VM, and set it to boot into the BIOS at first boot.

Booted it, fixed the time, set the boot sequence, rebooted.

During boot, I pressed F6 to specify hardware drivers, and pressed F2 to tell it I was doing an ASR operation.

I gave it the VMware hard disk controller drivers, it formatted the hard disk, and we moved on.

About the time I was starting to wonder when this was going to stop being a normal Windows OS load followed by a restore, and start being ASR, some unfamiliar windows came up. The first thing it did was c0mplain about not being able to find the backup at the UNC path listed in the ASR.SIF file. I tried to work around that but quickly came to the realization that either there were no network drivers, or Windows Setup was not allowing me to do any networking at that time.

So what next? How do I get the BKF file to where it can be seen? What would MS be expecting people to do with a physical machine at this point? I suppose it would either be a USB disk (which won’t work in ESXi), or a locally attached hard disk. So, I got creative with VMDK files. I loaded up an extra virtual hard disk on another VM, copied the BKF file to it, shut down that VM, and attached the virtual disk to the XP VM I was trying to restore. Didn’t see it, so I rebooted with it attached. It resumed the ASR process, but once again could not see the second hard disk. The only drives it would see were the C drive and the CD drive.

What finally worked was starting over with a larger VMDK, then shutting down the VM at the first reboot, attaching it to another VM that had a Bus Logic controller, and copying the BKF file to the drive that would become C during the ASR boot.

That done, I fired up the VM with the ASR process running, found the BKF on the C drive, and finished the restore. When done, it booted fine, logged in with cached credentials (the SBS2008 server was undergoing another restore at the time), opened the OST file just fine, and did not require re-activation, even though the disk (and its size) was different.

Since most Server VMs are made using the LSI Logic controller, it means having another XP VM handy to do this trick – or building one from scratch and then using it. Is it worth it to build one from scratch and then go through the ASR restore for the other? I’m not sure, having never done a restore using ASR on a fully loaded XP.

Anyway, it was an interesting experiment.

Tags: ASR, backup, ESXi, Windows XP

Today, after finishing up a test migration from SBS 2003 to SBS 2008, I deleted the SBS 2008 VM from the ESXi server to free up space for a real migration – but first, I used the built-in Windows Backup to make a one-time backup to a shared folder on my workstation via UNC path.

Then I got to thinking: This is as good a time as any to check out restoring SBS 2008, so let’s give it a go.

There are plenty of walkthroughs with screen shots on the web, so I won’t bother with that, I just want to comment on the process and give a brief overview for those who don’t need the screenshots and would rather just go through it with a few pointers.

First, I created a new VM with the same virtual disks, processors, and memory as the original. I suppose these could have been different sizes, as long as they were enough to cover it – but I didn’t test that.

Then, I attached the SBS 2008 DVD ISO image to the VM, set it to boot into the BIOS on first boot, and fired it up. Why did I set it to boot into the BIOS? Well, for two reasons actually. First, the time and date on the freshly created VM is often incorrect. In this case, the time was 1:30pm on the 24th. When I fired up the VM, it thought the time was 9:30pm. 8 hours wrong. SBS gets annoyed about things like that. The second reason was so that I could adjust the boot sequence.

Everything properly adjusted, I rebooted the VM and it started the SBS setup sequence.

At the proper junction, I told it to run a repair. I further told it to restore from backup. Here is where it got a little strange. It wanted me to select an operating system to repair, but there was none. I clicked the Next button and was rewarded with the option to do a Complete Windows PC Restore. Clicked that, and it looked around for a local backup device, didn’t find one. the available buttons were Retry, Cancel. At this point I started to despair, thinking MS had made an assumption about the backup device being local. Still, I clicked the Retry button first (more of the same), then the Cancel button on the third go-round.

The Cancel button turned out to be the right answer, because then there was an option for “Restore from a different backup”. Aha. Now we’re getting somewhere. Clicked the Next button. Was presented with a listof available backups. An empty list.

Man, if I had a lot of customer data and billable time invested in this, I would be on a serious emotional rollercoaster by now. MS could have presented this better. Still, there was a ray of hope: An Advanced button. I clicked it.

In the Advanced screen, there was an option to “Search for a backup on the network”. Bingo. Clicked that, confirmed the security warning, and Windows fired up the network stack.

Windows then prompted me for the location of the backup. I expected some trouble here, because the storage location was a UNC path to a workstation in a different subnet, on an XP machine attached to a non-trusting domain. However, my pessimism was unwarranted. MS got this one right. I was able to specify the UNC path to the machine (I used the IP address because I had no name resolution mechanism in place). It popped up an authentication dialog box and I was able to supply domain credentials, but it failed to connect to the workstation. I tried this a couple of times, just in case I had typed something wrong, but then I realized that I had fired up the VM in a network that had no DHCP server online. Well, that won’t work out really well, will it? I edited the VM settings and swapped it over to the network subnet that did have a DHCP server running, rebooted, and tried again. It worked much better that time. How about that? Anyway, once I got over that little hump, I was able to specify the full path to the storage location, and it found the backup.

From there it was pretty uneventful, which in itself is saying something positive for the process. I went and did some other things while waiting for the restore process to finish. Came back after a while and it was done. Rebooted the machine, and I had a fully functional SBS 2008, complete with users, data, configurations, etc. All was good. Didn’t have to re-activate, didn’t have to reboot to finish installing hardware.

Overall, not a bad process. Way better than loading a complete OS, booting into Directory Services Restore Mode, and restoring the backup right over the top of the freshly loaded OS that took so long to build.

Maybe there’s something to this SBS 2008 and Windows Backup thing.

Update: I ran this again with smaller disks (still larger than the 60gb requirement for SBS2008, but smaller than the original disks by 5gb). Way above the actual data size. It failed. Apparently it can’t resize on the fly, like Symantec Ghost has been able to do since the turn of the century. Sigh. Well, you can’t have everything. I guess this is likely to be a side effect of block level backups. Still, Storagecraft ShadowProtect can do this as of version 3.3, and they’re using the same VSS and block-level backup technology. Their restore operation is way different though.

Tags: backup, ESXi, SBS 2008

You can enable VNC connectivity to your virtual machines in ESXi. It’s actually quite easy to do, but there are some gotchas.

To enable VNC support, power off your VM and edit your VMX file (you can download it to your PC with Datastore Browser if you don’t want to edit it in place). It is a simple text file. Put these two lines in the file somewhere:

remotedisplay.vnc.port=”5900″
remotedisplay.vnc.enabled=”true”
remotedisplay.vnc.password = “yourpassword”

Replace “yourpassword” with a password of your choosing, of course.

Thanks to dragon788 for the password tip!

If you have multiple VMs on a single host, you’ll need to use a different VNC port for each. If you do that, then when you connect with the VNC client, just specify the port after the IP address, just like you would with a special port in a web browser or anything else. For example, if you have two VMs, you might connect to the first with just “192.168.0.1″, but with “192.168.0.2:5901″ for the second. It will look like this:

Once the lines are in the VMX files and the modified VMX files are in place on the host, fire up your VMs, then open your VNC client and try to connect.

I had difficulty with VNC Viewer free edition 4.1.2. It would seem to connect, but immediately disconnect. Sometimes I got the prompt to try to reconnect, which also did not work. It looked like this:

 To solve this problem, I used TightVNC Viewer instead of VNC Viewer Free Edition 4.1.2. It works well, and has better controls besides.

In order for the mouse to work properly, you will want to have VMware Tools installed. If the tools are installed, and you have mouse problems in VNC Viewer, make sure that the mouse driver is using the VMware Tools mouse driver, not the standard PS/2 mouse driver. It looks like this:

If it is not, then you can fix it as follows: Go to Properties, Driver tab, Update Driver. Choose “No, not this time”, “Install from a list…”, and “Don’t Search”. With “Show compatible hardware” checked, you should see VMware Pointing Device in there. Select it, finish, and reboot.

One downside to this setup: ESXi does not use password protection for VNC connectivity. Even if you add a line that should work, for example: RemoteDisplay.vnc.password = “12345678″, ESXi ignores it.

You should only use this in scenarios where you are securing the VM by other means, and never pass VNC through a firewall to your ESXi server. If you’re logged onto the VM, anyone can snoop or even gain administrative control through this. Use it carefully. My recommendation is that it only be used in a lab environment, not production.

Still, you’ve gotta admit it’s pretty cool.

Tags: ESXi, VMware Tools, VNC