ESX 3.5 Update 3 Release Imminent!

It seems the ESX 3.5 Update 3 release is imminent, as per some recent updates to the VMware website (screeny below)



Wonder if we'll get any timebomb action this time :D

Transcript of Best VMTN Community Roundtable Yet!

Hooo-rah! to Rod Haywood for transcribing VMTN Community Roundtable #22, which was in my mind the best roundtable yet (you got Krusty sized shoes to fill next week Chad :-). Bill Shelton was bang on point with just about everything he said. If you've spent any time with the guts of the SDK you'll know just how inconsistent it can be. In fact a while back I asked Carter and Steve how come the API was so quirky with guys like them working at VMware who clearly know better (otherwise they wouldn't have felt the need to write their respective wrappers). Their answer? "We've only been here for about a year." Bill Shelton falls into that category as well. Knowing how people think in those kinds of positions at VMware is very comforting indeed. I wonder what the Windows Azure API will look like. Actually no, I don't even care.

Clouds. Plenty of Them Around This Sunday Afternoon...

... and I'm not just talking about London. The topic of cloud or liquid or utility compute is perfectly suited for an edition of Sunday Afternoon Architecture & Philosophy.

Note that I said compute there. Indeed the cloud has many other components, but infrastructure guys like me will mainly be concerned with compute. And maybe storage. And of course what connects things to either of those 2. Hmmm. OK, maybe it's more than just compute, but for all intents and purposes I'm going to try and stay focused on compute.

So lets talk about apps. See what I did there? At the end of the day, compute is only good for one thing - running apps. But I can't see us getting to this fluffy land of external federated clouds without a fundamental change to how most applications in an enterprise environment run. Now don't get me wrong - the whole point of cloud compute from infrastructure up is that we don't have to change the apps. I get that. But in reality, they're going to have to change - they have to become portable, and any state needs to move out of the endpoint and into somewhere central. Why? Because it's gonna be a looooong time before _data_ is held in an external cloud, if ever IMHO. As Tim O'Reilly points out in his recent post Web 2.0 and Cloud Computing:

The prospect of "my" data disappearing or being unavailable is far more alarming than, for example, the disappearance of a service that merely hosts an aggregated view of data that is available elsewhere.

And I think that's the key point that a lot of skeptics are missing. As an individual I hold exactly the stance that Tim describes, and all I really care about are some photos, videos, my resume and my password database. None of that stuff is required in order for me to live. What stance do you imagine companies are going to have, who's very existence depends upon data and the manipulation thereof?

Cloud compute means exactly as the name implies. COMPUTE. As in run up a compute engine (ie. an OS + App + State stack), throw some data at it, get some data back, job done. At no point did that data originate from, persist in (for any meaningful amount of time), or return to the external cloud. The security, availability and integrity of that data during transit and processing is by no means trivial, but compared to storing that data in the external cloud it is.

Which leads me in a roundabout way back to why apps need to change in order for internal compute clouds to reach their full potential and for external compute clouds to become really viable. Apps need to be delivered predictably and efficiently, that we may throw data at them. Whether that is achieved by virtualising them, streaming them, packaging them the traditional way, the choice is yours. But start thinking about it now, lest your clouds do nothing but rain on you.

VirtualCenter 2.5 Update 3 Upgrade Process - here we go again!

It seems the VirtualCenter upgrade process is not getting any better. I can't for the life of me understand how bugs like this got through with the Update 2 release, but they did and are one of the primary drivers for my company to roll out Update 3 asap (that and the security fixes). But lo, there are new upgrade problems afoot, notably this one which I have encountered 3 times now. Duncan called it out a few weeks back.

Now what really grinds my gears is that the most important fixes (for me anyway) are security related and of course the fix for the guest customisation bug. That is, binary patches - nothing at all to do with the database. In fact I can't find anything obviously database related in the release notes, and this is somewhat validated by the fact to get around this we need to append a "MINORDBUPGRADE=1" argument to VCDatabaseUpgrade.exe (the DSN, UID and PWD arguments don't appear to be necessary). So for anyone at VMware reading this, STOP TOUCHING THE VC DATABASE WHEN YOU DON'T HAVE TO. Minor DB upgrade? WTF? You're risking the VC database and ruining another persons saturday (now we need a Unix admin, a Windows admin _and_ a DBA to upgrade VC) for a MINOR UPGRADE?

Additionally, the jre binaries are not upgraded correctly as we found out when the Sun Ray environment in our lab broke after applying U3 (Sun have a KB article about this that I can't find at the moment). A clean install had no such problems however.

If VMware are going to continue with these monolithic style updates so frequently (Update 1 in April, Update 2 in July, and now Update 3 in October), they need to get their chi together. Tomcat and JRE security related bugs come out all the time, and if you work in a regulated environment then you have no choice but to patch ASAP. But having to touch the database in order to do so is the opposite of cool. Be cool VMware, be cool!

UPDATE: Here's that Sun KB article I was referring to... it actually mentions Update 2 but the same applies for Update 3

(Red) Sun Rising...

Sun are keeping suspiciously quiet regarding their virtualisation offerings, both present and future, and you know what they say about the quiet ones. There doesn't seem to be a lot of material out there tying the various pieces of their puzzle together, and it's entirely possible this is intended to keep everyone's focus on VMware / Citrix / Microsoft. I hear a little voice... oh, sorry, you too Red Hat.

But check out what's in the pipeline with storage (starting page 13). Holy fuck - did your head just explode too? Or hows about how ALP shapes up against other remote display protocols (we've tested this first hand where I work - over high latency connections, there is _nothing_ in it between ALP and ICA). Put those pieces together with Lustre, Zones, xVM, Ops Center, and Sun Ray, all glued together with Java... and VMware should be shaking in their boots. We may well see the old kings of the datacenter back with a vengeance in the next 12-24 months.

System Center Virtual Machine Manager 2008 RTM's!

You read it here first... well, second besides the actual announcement.

I'll definitely be checking it out soon as it's available for end users!

Update: The eval is available for download already!

HP "Virtualization Blade" - Marketing Bullshit 1 / Virtualisation Architects 0

I'll start (as I often do with negatively titled posts) by saying that I love HP kit. No I'm not being sarcastic, back when I was a support guy I actually resigned from a place because they were going to switch their server vendor of choice away from HP. But for fucks sake, this BL495c "virtualization blade" business is _really_ getting on my nerves. Rather than explain, help me out by doing the following:

1. Google "HP Virtualization Blade"
2. Ignore Mike's #1 rank in the results (nice job Mike, how the fuck did you take top spot from HP themselves in under 1 day :D).
3. 4 or 5 results down you should see "HP ProLiant BL495c G5 Server Blade - product overview". Hit that link.
4. On the resulting page, ignore all the marketing bullshit and cast your eyes over the "Support" section of links to the right of the blade image.
5. Open the "OS support" link in a new tab. Change to that tab, and hit the "Vmware" link.
6. Go back to the main product overview page, and open the "Software & Drivers" link in another new tab.

Or if you're too lazy, have a look here and here.

Now am i going blind, or is there a complete lack of VMware support for this "virtualization blade"? Thanks for that HP. Now guys like me have to fend off a barrage of enquiries from support and management asking "why aren't you looking at the HP virtualization blade?". Ironically, Citrix XenServer 5.0 is listed as supporting the BL495c... is anyone even using that? Even if there was VMware support, good luck with using that 10GbE outside of the chassis - there isn't a 10GbE switch available for the C-class yet. And let's not ignore the other touted feature, SSD. As Mike points out in his post, disks in blades are next to useless anyway (although in my mind the future is PXE rather than embedded).

No doubt the VMware support and 10GbE switches will come in time, but until then HP should withdraw the marketing BS. It doesn't do them any favours, and no doubt posts like this will just serve as ammo for their competitors. I look forward to the day when I won't have to write such posts in the first place!

VM Template for Citrix Provisioning Server

A rather odd bug with VirtualCenter is the inability to deploy VM's with a SCSI controller but without a disk... even creating a template from a VM that has a SCSI controller but no disk results in a template with no SCSI controller (you then have to convert it to a VM, re-add the SCSI controller, then convert back to template. Only to find the SCSI controller stripped during the deploy from template. There's 10 minutes of my life I'll never get back).

If you've been reading this blog for any length of time you'll know I'm not exactly a fan of Citrix XenServer, but Citrix Provisioning Server on the hand is _very_ cool (albeit prohibitively expensive and not without it's drawbacks... another post maybe). For the uninitiated, Provisioning Server streams a disk via the network. But obviously the streamed disk needs to be access via a disk controller (duh!). Which is why I want to create a diskless template in the first place.

Before firing up the trusty PowerShellified version of Notepad2, i did a cursory search of the VI Toolkit forum to see if someone had done this already... and surprise surprise, Cool Hand LucD had done my work for me.

So yeh, now all I need to do is deploy my scsiless and diskless template with new-vm and call the function from LucD, and all is well in the world - big ups to LucD.

/me makes W shape with fingers on one hand while simultaneously pounding fist on chest with the other

Future ESXi Version Call to Arms!

While there wasn't a lot of concrete details that came out of VMworld, one thing is for certain - VMware are working on a _lot_ of new functionality for their next major release. Of particular relevance to us at vinternals is the host profiles feature, as it provides the same functionality as Statelesx, but is done in a much more user friendly way. Which is fine - it's not like we threw in out jobs and tried to position statelesx as a commercial product, and in some ways it's a validation that our idea was a good one.

But VMware need to ensure they implement the other half of the solution, ala the client initiator. Without this, there is still an unnecessary manual task of joining a host to a cluster in the first place. You may think this isn't such a big deal, but if your hosts are PXE booted then a client initiator is an absolute requirement.

Fortunately for us, there is at least one senior guy at VMware who gets all this - Lance Berc (I get a laugh eveytime I see his 'novice' status in the VMware forums - for fucks sake, this is the guy who wrote the original esxtop). So far most attention has been on his post-build configuration scripts, but Lance put his C skills to work and released the crucial client initiator piece as well as a 'midwife' which essentially performs the same duties as statelesx. Put all this together and you have a truly automated, scalable, liquid environment - the likes of which is usually only seen in compute clusters. Except this time it's a _virtual_ environment.

VMware seem to be taking notice of the need for cluster wide configuration automation with host profiles and the distributed virtual switch, we as customers need to make sure they understand the need for the client initiator functionality as well. The 'midwife' functionality would also be nice if it was wrapped into VirtualCenter, but if it isn't then maybe Statelesx will have some longevity after all, even if it is somewhat more limited to automating the application of a host-profile that is defined elsewhere.

So here's the call to arms. We as customers have the strongest sway with regards to product features. And with a new version of the platform in development, now is the time to start hitting our account managers inboxes with requests for this functionality. Hell, just send 'em a link to this post if it makes it easier - the important thing is to push this through the account channels, not Lance (you'd just be preaching to the converted), and the time to act is now!