motogobi

This completely saved my aching head this morning when we had to update the VLAN on some freshly-built ESX hosts:

Esxcfg command help

Thank you, Eric Siebert!

So this is not really news, but is now big official news: the 4.1 release of vSphere is the last supported version of ESX. VMware is finally dropping the Service Console. Moving forward, ESXi will be the core hypervisor technology at the center of VMware’s virtualization strategy (for now). Can’t say I disagree, especially if you understand the reduced overhead and patching needs of ESXi - 1/10th the patching requirements? I’ll take it:

During VMworld 2010 in San Francisco one of the big messages being pushed out to the attendees is that VMware ESX will no longer have a future. The 4.1 release will be the last release of VMware ESX, future releases will only come with ESXi. Dauglas Phillips interviewed Sean and Charu from the ESXi team about what this will mean for customers.

Our 4.1 upgrade just changed a wee bit, I think.

Ran into this error this morning, which of course took down one of our (1000+ VM) vCenter environments:

The vCenter Server’s vpxd logs contain entries similar to:

An unrecoverable problem has occurred, stopping the VMware VirtualCenter service. Check database connectivity before restarting. Error: Error[VdbODBCError] (-1) “ODBC error: (23000) – [Microsoft][SQL Native Client][SQL Server]Violation of PRIMARY KEY constraint ‘PK_VPX_GUEST_DISK’. Cannot insert duplicate key in object ‘dbo.VPX_GUEST_DISK’.” is returned when executing SQL statement “INSERT INTO VPX_GUEST_DISK (VM_ID, PATH, CAPACITY, FREE_SPACE) VALUES (?, ?, ?, ?)”

The link to the VMware knowledgebase article is here: vCenter Server service fails with the error: Violation of PRIMARY KEY constraint ‘PK_VPX_GUEST_DISK’

The curious part? That issue is addressed specifically by vCenter Update 1, Build 208111 and we’re running 208111. In any case, shutting down the vCenter service (ok, it wouldn’t run anyway) and running the SQL script supplied in the KB article did the trick and fixed that which should probably already have been fixed. Still super happy we’re not running on Oracle anymore, though…

If you haven’t heard about disk alignment and you’re using virtual machines, you owe it to yourself and your most-likely-growing infrastructure to understand what alignment is all about. On a small scale it’s almost unnoticeable. But I can tell you that on a large scale it becomes a major pain for you or your storage infrastructure team.

One quick tip: to check your disk offset on Windows systems, simply launch msinfo32.exe from the Run menu. See the thumbnail of this post for a screenshot.

From VirtualGeek’s excellent post:

The purpose of alignment is to minimize extraneous internal array operations. All arrays have internal constructs that are generally a function of the RAID model (and also the filesystem alignment, and in some cases logical page table constructs in virtually provisioned models).

<snip>

All the funky goodness is done via either filesystem or another (pages commonly) abstraction on TOP of the RAID abstraction. Think of a 4K NTFS IO operation in a Guest making it’s way down to the array. Once it gets there, let’s say the array has a 64K stripe, but a 1MB “page” used for these fancy features. Falling into two 1MB logical memory pages as an example – where statistically it’s much more likely to land on a boundary if the volume is aligned on a 4K boundary.

It’s very worth your time to delve into this article and find out how your environment is set up, like right now. You might find your templates are mis-aligned, or in our case, that VMware Converter does not properly align disks on conversion (wonder-app Platespin Migrate does, in fact, give you properly-aligned disks).

So some interesting stuff has fallen out of the investigation we’ve done regarding how VMware High Availability handled five of our hosts falling off the network last week. In speaking with VMware’s support staff I’ve learned a few things to keep in mind when planning architecture, as well as how to respond to something like this in the future (hint: don’t panic). Turns out, ESX didn’t really fail as much as it politely gave up, opting to take the route that seems to be the least harmful to our guest VMs’ operating systems. Admit it, we’ve all been there: you’re working on a Windows machine, it’s not responding, and you get to the point where you just hit the reset button. Well, VMware will let you – and only you – take that final step towards OS recovery during an event like this.
continue reading…

So we ran into this last night and are trying to work through why things happened the way they did – which is to say, why we had some support personnel on the phone who said “it shouldn’t do that.” The long and short of what a split-brain scenario is this:

You have two hosts with VMs running in an HA cluster. Host 1 gets completely isolated from the network – no service console, no guest net connections, nothing – but the VMs are still running on it. If you have your HA settings set up to not power down those virtual machines on isolation, HA has already started up those VMs on Host 2 – and when Host 1 reconnects to the network (with it’s never-shut-down-VMs) you’ve now got two VMX processes running in memory on two hosts. This is not good.

continue reading…

I’ll have to wait for the paperwork to come through in a bit, but I nailed my VCP410 exam this morning. Ah, the load off my chest at the moment…

– mike

This little tidbit from The Lone Sysadmin saved our bacon this morning: if you’re finding it impossible to migrate a VM off of a host because of a stuck VMTools installation process, there’s a quick way to kill this process off via the command line to get things moving along. First, you need to know the process ID of the VM you’re working with (run this from the host where the VM is currently living):

/usr/bin/vmware-cmd /vmfs/volumes/datastore/vmname/vmname.vmx getid

This should return something like “getid() = 192″

Using that ID you can then cancel that tools install:

/usr/bin/vmware-vim-cmd vmsvc/tools.cancelinstall

Voila! No more tools install, and migration should work normally. Huge thanks, again, to Bob over at The Lone Sysadmin!

If you end up using VMware’s VI Client to connect to multiple vCenter servers or ESX/ESXi hosts, you might find yourself a little annoyed at how many saved connections show up when you go to launch a new connection. This becomes ever more annoying when you’re connecting to multiple servers named somewhat the same as the client will start auto-completing your selections. This has reached it’s pain point this week as we transition to similarly-named vCenter servers and I keep fat-fingering what I’m typing.

If you want to clear that saved connections dialog, it’s a simple registry edit in XP. Navigate to:

HKEY_CURRENT_USER\Software\VMware\VMWare Infrastructure Client\Preferences\RecentConnections

and simply delete the connections you don’t want (DO NOT delete the entire key, just the connections in that reg key). Enjoy your clutter-free VI Client…

So I’ve been restoring some Windows servers from NetApp snapshots today, specifically single hard disks that had been having problems (long story involving Windows problems, etc). I found this pretty easy to do once I got the syntax down – basically, all I was looking to do was to restore the C: of a server, but keep it’s D: intact – that way I’d keep the most recent data, in this case some SQL files, but could roll back to a point where the Windows OS was a little less hosed up. Mostly for my own quick reference in the future, this is how I cranked a bunch of these out.

continue reading…