Posts Tagged ‘ESXi’

If, like me, you’ve been using VMware Workstation for a long time, it is quite possible you’ll have dozens of “Workstation” virtual machines littering up your PC. Now you’ve just built a shiny new ESXi virtualisation server, is it possible to convert those ‘desktop’ VMs into something ESXi can handle?

The answer to that is a definite ‘yes’. The tool of choice is a freebie download from VMware themselves, called the VMware vCenter Converter Standalone 4.0.1. It’s a versatile tool, too: if you’ve got Microsoft Virtual PC VMs, it can process them; it will even convert a Symantec Ghost image of a (real, physical) PC into an ESXi-compatible VM. Actually, it can even convert live, running physical PCs into ESXi VMs, which seems devilishly clever to me!

It’s a big download (103MB or so). When you go to install it, you get a choice between a ‘local’ and a ‘client-server’ installation. I picked the local option, so that all VM conversions will take place directly on my Windows 7 desktop (as opposed to me managing them from my desktop but all the heavy lifting taking place on a remote server -definitely an option worth investigating at work!). The conversion process itself is very simple: point the Converter tool at the .vmx file which represents your “desktop” VM’s configuration file; connect the Converter to the ESXi server; choose which of the ESXi’s datastores you want the converted VM to end up on; and then sit back and wait.

In pictures, here’s how the process looks for an XP VM I had with a 30GB virtual hard disk. Once the program is running, select the Convert Machine option from the top toolbar:

You then select your source type (in my case, a VMware Virtual Machine) and point the tool at the .vmx file for that virtual machine:

You then attach to your ESXi server, providing the relevant log on details:

Probably the most important bit is then to specify whereabouts on that ESXi server (which ‘datastore’ in the jargon) you want your VM to be transported to:

You then get a summary screen of what’s about to be converted, and each section of the conversion process can be edited:

So, although my original desktop VM had been assigned 2GB of RAM, I might only want to assign 512MB (for example) to the converted VM when it migrates over to the ESXi server. Click ‘Next’ after that and you get one final confirmation of what’s about to happen. Click ‘Finish’ on that screen, and it all starts happening. My 30GB XP VM was converted and moved to my new ESXi server in 25 minutes flat, which seems pretty reasonable to me. The VMware Tools that were previously installed in the ‘desktop VM’ had to be upgraded manually once the machine was running on the ESXi server, but otherwise everything else was taken care of perfectly.

Another issue that arose with this specific VM Guest conversion was that the XP guest suddenly went silent on me: no sound device existed in the converted machine where one had existed and functioned just fine in the original ‘desktop’ version. That’s curable, however, by following these instructions in the VMware knowledge base, so no permanent harm done. (It raises the question, I suppose, of why one would ever actually want a VM running on a remote server to pipe sound back to your desktop PC via the network: you’re always going to have latency/contention/traffic volume issues, after all. Still it’s nice to know you can do it if you really want to.) Having followed those knowledge base instructions, you still won’t be able to get the XP VM to do sound from within the vSphere Client, claiming that no audi device exists in the XP VM at all; but if you use a Remote Desktop Connection to it, you’ll find the XP machine able to use the ‘Microsoft RDP Audio Driver’, and sound will then be piped across the network.

It’s all incredibly neat and works beautifully.

(Just one niggle: sometimes, when I’d filled in the ESXi logon details and clicked Next, I was told that my session had not been authenticated -and the conversion process won’t take place until it has been. The fact that I definitely supplied the correct username and password wasn’t, apparently, enough. Well, it turns out that this is quite a common problem that (apparently) arises from time differences between your client session and the ESXi server clock. A reboot of your client (in my case, of my Windows 7 desktop) was sufficient to allow me to re-start the wizard and this time authenticate perfectly.

One of the biggest niggles I had (and continue to have) with VMware’s ESXi hypervisor is that its management tool (the “vSphere Client”) won’t run on Windows 7. It installs well enough, but try and actually run it and you’ll simply be told:

Click the OK button there, and you’ll get told rather more mysteriously:

And that’s a clue (to the initiated, at least!) that it’s something wrong with the .NET framework on Windows 7 that is causing all the grief. The fix for this problem has been around for a while and is scattered on various websites in slightly different variations across the wide expanses of the Interweb, so I claim absolutely zero originality for what follows. I’m only repeating it here so I can find it easily in the future and in a version that worked for me!

You need to use a PC running some version of Windows which is not Windows 7 for what follows. I happened to have a VM running Windows XP kicking about the place: it had Service Pack 3 installed, but that was about the only update it had ever received. I didn’t fancy taking the usual ‘Windows Update’ route, because that would have taken for ever, so instead I visited Microsoft’s website and obtained the .NET Framework 3.5 downloader by itself. Run that once it’s downloaded, and the entire .NET Framework gets downloaded and installed (all 60MB of it). Then you visit Microsoft again and download the Service Pack 1 for the .NET 3.5 Framework bootstrapper. Run that, and after another 52MB, you’ve got the SP1 version of .NET 3.5 and you’re in business. (I realise this sounds a long-winded way of doing it: the alternative that several other sites take is to simply provide a link to download the relevant file that we need from their own private websites. But I prefer not to obtain my system dlls from non-authorised sources, and I suspect others might think likewise! Doing it this way, therefore, you can be sure that the files you’re about to copy to your Windows 7 system are kosher Microsoft ones).

Anyway, once you’ve got a non-Win7 .NET Framework 3.5 SP1 installed, find the C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 directory and copy the system.dll file you find there to your Windows 7 box. It has to go in a very specific location (that will only exist after you’ve installed the vSphere client, so do that first if you haven’t already done so). That location is: C:\Program Files (x86)\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\lib. If you’re not running the 64-bit version of Windows 7, that first bit will be plain old ‘C:\Program Files’, without the ‘(x86)’ bit, but since I am running everything 64-bit these days, the x86-version of the path is what I used. If the “lib” directory doesn’t already exist inside the Launcher folder, just create it and then copy the .dll to there.

In that Launcher directory, too, you’ll find a file called VpxClient.exe.config. Right-click that and open it in Wordpad. Welcome to the wonderful world of XML editing! The rules here are simple: you add these three lines to the file, immediately after the </appSettings> one and immedately before the final </configuration> one:

<runtime>
<developmentMode developerInstallation="true"/>
</runtime>

Make sure the double quotes around the word ‘true’ there are proper ones, not some fancy curly version that assorted web browsers or word processors might add to the mix. Save the modified version of that file which should end up looking like this in its entirety:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.net>
       <connectionManagement>
           <clear/>
           <add address="*" maxconnection="8" />
       </connectionManagement>
  </system.net>
 <appSettings>
   <add key = "protocolports" value = "https:443"/>
 </appSettings>
<runtime>
<developmentMode developerInstallation="true"/>
</runtime>
</configuration>

The new additions are highlighted there in red.

Finally, you need to add a new DEVPATH environment variable to your system. Click the Start “orb” button in your Windows 7 PC, then right-click the Computer menu option and select the Properties item from the context menu. Finally, click the Advanced system settings option from the left-hand pane. On the Advanced tab of the resulting dialogue box, click the Environment Variables button:

In the System variables section of the resulting screen, click the New button. Type in a new variable name of DEVPATH, and set its value to be the lib directory where you stored the system.dll file copied from your non-Win7 box. In other words, in my case, that would be C:\Program Files (x86)\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\Lib:

Click OK as many times as it makes the various dialogues and their pop-up boxes disappear, and you should then be able to run the vSphere Client on your Windows 7 PC without a drama. As is apparently pretty standard no matter which version of Windows you’re running on, you’ll receive an initial ‘certificate warning’, but the correct response there is to select to install the certificate and then click the Ignore button:

Once that’s done, you’re definitely in the business of managing your shiny new ESXi server.

I’ve been doing virtual machines since 2000, which makes me a bit of an old-timer, I would think. I invented the laptop rac using a single virtual machine and taught it in Oracle University classrooms from about 2002 on, which was something of a world first. I’ve been banging on about the virtues of virtualisation for a long time… you’d think I’d therefore get it right when it comes to putting it into production, wouldn’t you? But no. I’ve stuffed up. In fact, I’ve behaved like I’d never met a virtual machine before. A virtualised virgin, if you like.

Beguiled by the swift, elegant simplicity of the Citrix XenServer installation and included management tools, I’ve persuaded the powers that be at work to dedicate a 32GB, 8 CPU monster server to running XenServer. I’ve even persuaded them to do something of a first this financial year and part with about AU$6000 so that I can upgrade the storage from a paltry 400GB to a more useful 3000GB, all with a view to combining every test and dev database we’ve got onto a single server, but running in discrete, virtual servers for the purpose of easy snapshotting, backing up, migration and so on.In the process, we would free up two physical servers, one of which could house a small database that all our other databases link to for ‘globally unique’ information. That would free up 6GB of RAM on one of our other servers, thus enabling the two databases running there to increase their buffer caches and get their web response times down further from their already pretty good 0.6 seconds. Wins all round.

Except I chose Citrix XenServer.

It’s not a bad virtualisation product. It’s just immature compared to the likes of VMware. A core requirement was the easy ability to create snapshots, to then navigate back and forth up and down the snashot tree as required. XenServer is bloody awful at snapshotting anything (promised to be fixed in the next release). Another core requirement was the ability to export a virtual machine for backup purposes: one of my 80GB VMs took 11 hours to export with Citrix. On VMware ESXi, it takes 36 minutes. God knows why, but the difference -functionally- is enormous. Finally, as reported in these parts yesterday, XenServer throws a complete mental fit when confronted with Centos 5.4; ESXi just took it in its stride. (Oh, and as another aside, XenServer refuses to run Windows in a VM unless hardware virtualisation extensions are present; ESXi doesn’t appear to give a stuff, and runs them just fine and with seemingly perfectly acceptable performance results).

The XenServer is going, in other words. And we’re switching to ESXi.

I have my problems with ESXi, too, which I’ll no doubt document before long. The fact that its GUI management tool doesn’t run on Windows 7 was a bit of a killer, for example, but I have found a way around that. The licensing is also a complete pig’s breakfast and I’m still trying to get my head around that. But, all in all, ESXi does what we needed virtualisation to do, today, whereas Citrix XenServer doesn’t and won’t until the proverbial “next release”.

I apologise to my reader(s) for having eulogised a fundamentally dud technology (at least as far as we are concerned at work) for far too long. Normal service will be resumed soon, I hope!