Posts Tagged ‘VMware’

Eating Your Own Dog Food

October 8, 2010

This is a post I’ve been meaning to write for a while now, but for one reason or another I kept putting it off. So when Mike Laverick asked me about what subjects I wanted to cover in my Chinwag, I finally got around to talking about it in public. I say in public, because this is something I and many others been saying to VMware behind closed doors for a bloody long time now. And as Mike pointed out during the Chinwag, there’s certain sense of irony in applying this phrase to VMware, given that Paul Maritz is credited with inventing it (or at the very least popularising the saying in the IT world) over 20 years ago.

I’m not writing this post to be inflammatory. Nor do I feel the need to justify my comments any more than what was said in the Chinwag. I just feel that a little more clarity and elaboration is needed – when we started on the topic the conversation was skirting around several things at once, all of which were pretty negative. And although I wouldn’t go as far to label those first 20 or so minutes as “VMware bashing”, I can understand how it might be seen that way. So let’s get that straight – when I say VMware should eat their own dogfood, I mean it constructively. I’m not talking about stuff like vCloud Director 1.0 requiring a database from the least-VMware-friendly company on the planet, or that the vSphere Client isn’t supported as a ThinApp package. I’m talking about something much more fundamental than that. I’m talking about glass houses and throwing stones.
(more…)

Enter the Appliance

June 9, 2010

Today’s announcement of an expanded VMware / Novell partnership was interesting in many ways… the licensing aspect, the support aspect …but none moreso (for me at least) than the virtual appliance aspect. In case you missed that part, VMware will be adopting SUSE Linux Enterprise Server, SLES, as the single platform for their virtual appliances. Whether you agree with the platform choice or not (fortunately the company I work for has been a SLES shop from day one), sometimes it’s more important that there actually is a standard, rather than what the standard is. This is one of those times.

I’ve ranted in the past about the problem with virtual appliances. Everything from the lack of a standard Linux platform even within a single vendor (let alone amongst multiple vendors), to the additional overhead such a model of software distribution would place upon software vendors, to the security needs of the Enterprise around patch response times etc. And today, every single one of those arguments has been nullified in one fell swoop. Hallelujah, someone was listening after all!

If you’re a software vendor looking to adopt the virtual appliance model to distribute your wares then I have some advice for you – if you’re not using SLES for the base of your appliance, start doing so. Now. This partnership will mean doors that were previously closed to virtual appliances will now be opened, but not to any old virtual appliance – it will need to be built on an Enterprise grade distro. And SLES is most certainly that.

You all know I’m not one to drink the Kool-Aid, but it’s things like this that really show the leadership VMware has over the rest. My hat is officially tipped to whoever brokered this deal, it’s exactly what was needed.

New HP CIM Patch Released, Update Manager Still Can't Apply It.

April 28, 2010

A new version (1.3) of the HP ESXi Offline Bundle has been released for ESXi 4.0 Update 1. Now I don’t normally tend to post about patch releases because… well, I just don’t really see the value in posting that a patch was released and leaving it at that. But this is a little different.

Because you _still_ cannot apply this patch via Update Manager.

So once again I’ll ask the question of VMware – what is the point of having an automated patch tool if it can’t actually apply patches like these? Clearly the HP patches are packaged in accordance with VMware requirements, because they can be installed via the vSphere CLI. Yet there is still not an easy way to add patches like this to the VUM repository. Cisco patches seem to be available via a VMware provided online repository, but I’m not asking for that – there needs to be a way to manually add patches to local VUM servers, without pointing the VUM server at a website.

Update Manager does on the other hand continue to offer somewhat useless and redundant guest patching functionality, and even more useless application level remediation for things like BizTalk server. But it still cannot handle patching a host that happens to be running a vCenter VM (yet I can manually VMotion said VM around). And there’s still the unscalable 1:1 relationship between vCenter and Update Manager. I’m not sure what the Update Manager team are working on, but they really should forget about the guests and concentrate on the host patching capabilities, which are far from ideal currently.

Update Your Bookmarks – VMware Orchestrator Community Launched!

April 25, 2009

I’m not sure how many vSphere beta participants spent some time with the new version of VMware Orchestrator, or vCO, but I certainly did and I’m happy to say the product completely rocks. I have looked at a few of the orchestration tools on the market, and this is easily the best I’ve seen to date for orchestration of the VMware layer.

I’m not going to post more about it until GA just in case I inadvertently divulge something that I shouldn’t and get in trouble, but everyone should add the new vCO Community Site to their bookmarks, and lookout for a new section on vinternals.com similar to the VI Toolkit Mastery section, dedicated to vCO Mastery!

Thin VMDK's Not Supported on FC Datastores!?!?

March 27, 2009

I know, this one caught me totally by surprise as well, but it’s true. We don’t actually use this switch when creating vmdk’s, but after seeing some _shocking_ statistics from our environment, whereby most VM’s with additional vmdk’s were using under 10% of their provisioned space, I decided to look into it.

Now I certainly don’t claim to know everything, so for non-obvious stuff like this I usually look into is as much as I can, then fire off a query to my VMware account team (well… just to the 2 engineers on our account) to see if there’s anything I have missed that would stop me from giving the OK to use it in our environment. Boy, good job I do this (and good job I have some very good SE’s)- the answer I got back isn’t covered in _any_ of the existing documentation.

The official word from VMware is that thin vmdk’s (ie those created with vmkfstools -d thin) are currently not supported for production use on FC datastores. Again, since it’s not possible to create these through the UI I imagine that there aren’t too many people out there affected by this. Even though we aren’t affected, and I can understand why VMware would take such a stance, I’m a bit miffed that there is no mention of this in any documentation I can find. I’m sure that will be changing shortly!

VMware 2009 Product Lineup

January 7, 2009

I was under the impression that some of these products were still in super secret squirrel status, but as they’re now appearing on the VMware Products homepage, I guess that’s no longer the case!


Since you’re all going to go and check out the VMware spiel anyways, I won’t bother repeating it here.

What I will say though is that I’m not sure how wise it is for VMware to simultaneously spread themselves even thinner by releasing more products, and eat into the opportunities for ISV’s. 2009 is going to be a tough year for everyone, and a healthy ISV market is good for a software company. The last thing VMware should be doing is try and offer everything themselves, thus driving ISV’s like Veeam, Quest and the many others into Microsoft’s camp where they will no doubt be welcomed with open arms!

Deploying OVF's with the VMware OVF Tool

January 1, 2009

I finally got around to OVF’ing a Windows XP build. Although I have an unattended setup XP .iso which makes building XP VM’s hassle free and pretty fast, it’s obviously nowhere near as hassle free and fast as deploying from OVF!

Although you can import OVF’s with VMware Workstation, it’s a bit cumbersome. I’ve also had some wierd experiences with it, such as the “split disk into 2GB files” option being ticked and greyed out when I didn’t want the option selected (both for export and import operations). VMware Player is no better, as you can’t control where the OVF is deployed to. Back when we were developing statelesx, we used a Java based version of the OVF Tool from VMware to create the virtual appliance package. But someone at VMware has been quietly beavering away (I say quietly because I haven’t seen _any_ publicity from VMware about this tool), and it’s now at a 1.0.0 build (although still labelled as a “technology preview”).

And just like Boche, they’ve injected some steroids into the tool… for example (note I haven’t tried this… yet) you could pull an OVF straight off a webserver and plonk it onto a host, specifying datastore and portgroup details with:

ovfTool “http://my_ovf_server/ovfs/myAppliance.ovf” “vi://username:pass@my_vc_server/my_datacenter/host/my_host&datastore=my_datastore&net:ovf_network_name=vc_network_name”

So check it out, it’s a nice and fast way to deploy OVF’s locally for use with Workstation or Player, but also has some serious enterprise functionality.

ESXi 3 Update 3 – Free Version Unshackled, hoo-rah!

December 10, 2008

I’m not going to try and claim credit for this development, but Rich Brambley (the only blog with a description that I feel outshines my own 🙂 broke the news today that the free version ESXi 3 Update 3 appears to have a fully functional API. I plan on testing this out tomorrow, and will report back as I’m sure others will too!

UPDATE The great Mike D has beaten me to it. Looks like all systems are go for the evolution of statelesx… 😉

UPDATE 2 Oh man… who the !#$% is running QA in VMware? What a shocker!

VMware View – Linked Clones Not A Panacea for VDI Storage Pain!

December 10, 2008

Why do I always seem to be the bad guy. I know the other guys dont gloss over the limitations or realities of product features on purpose, but sheesh it always seems to be me cutting a swathe of destruction through the marketing hype. Somehow I don’t think I will be in contention for VVP status anytime soon (I’m sure the profanity doesn’t help either but… fuck it. Hey it’s not like kids read this, and I’m certainly not out there doing this kind of thing).

As any reader of this blog will be aware, VMware View was launched a week or so ago. Amongst it’s many touted features was the oft requested “linked clone” functionality, designed to reduce the storage overheads associated with VDI. But it may not be the panacea it’s being made out to be.

My 2 main concerns are:

1) Snapshots can grow up to the same size as the source disk. Although this situation will probably not be too common, you can bet your life that they will grow to the size of the free space in the base image in a manner of weeks. I’ve spent an _extensive_ amount of time testing this stuff out to try and battle the VDI storage cost problem. But no matter how much you tune the guest OS, there’s just no way to overcome the fact that the NTFS filesystem will _always_ write to available zero’ed blocks before it writes to blocks containing deleted files. This means if you have 10GB free space, and you create and delete a 1GB file 10 times, you will end up with no net change in used storage within the guest however your snapshot will now be 10GB in size. Don’t belive me? Try it yourself. Now users creating and deleting large files in this manner may again be uncommon, but temporary internet files, software distribution / patching application caches, patch uninstall directories, AV caches and definition files, temporary office files… these things all add up. Fast. Now of course each environment will differ in this regard, so the best thing you can do to get an idea of what the storage savings you can expect is take a fresh VDI machine, snapshot it, and then use it normally for a month. Of if you think you’re not the average user, pick a newly provisioned user VDI machine and do the test. Monitor the growth of that snap file weekly. I think you’ll be surprised at what you find. Linked clones are just snapshots at the end of the day, they don’t do anything tricky with deduplication, they don’t do anything tricky in the guest filesystem, they are just snapshots. Which leads me to my next major concern.

2) LUN locking. We all know that a lock is acquired on a VMFS volume whenever volume metadata is updated. Metadata updates occur everytime a snapshot file is incremented, at the moment this is hardcoded to 16MB increments. For this reason, the recommendation from VMware has always been to minimise the number of snapshotted machines on a single LUN. Something like 8 per LUN I think was the ballpark maximum. Now if the whole point of linked clones is to reduce storage, it’s fair to assume you’d be planning to increase the number of VM’s per LUN, not decrease them. In which case houston, we may have a problem. Perhaps linked clones increment in blocks of greater than 16MB, which may go some way towards solving the problem. But at this time I don’t know if that’s the case or not. Someone feel free to check this out and let me know (Rod, I’m looking at you 🙂

Now of course there are many other design considerations, such having a single small LUN for the master image and partitioning your array cache so that LUN is _always_ cached. It’s a snap’ed vmdk and therefore read only so this won’t be a problem. Unless you dont have enough array cache to do this (which will likely be the case outside of large enterprises, or even within them in some cases).

In my mind, the real panacea for the storage problem is statelessness. User environment virtualisation / streaming and app virtualisation / streaming are going to make the biggest dent in the storage footprint, while at the same time allowing us to use much cheaper storage because when the machine state is empty until a user logs on, it doesn’t matter so much if the storage containing 50 base VM images disappears (assuming you catered for this scenario, which you did because you know that cheaper disk normally means increased failure rate).

So by all means, check View out. If high latency isn’t a problem for you, there’s little reason to choose another broker (aside from cost of course). But don’t offset the cost of the broker with promises of massive storage cost reduction without trying out my snap experiment in your environment first, or you may get burnt.

UPDATE Rod has a great post detailing his thoughts on this. Go read it!

UPDATE 2 Another excellent post on this topic from the man himself, Chad Sakac. Chad removes any fears regarding LUN locking, which IMHO is only possible with empricial testing, which is exactly what Chad and his team have done. Excellent work, and thankyou. With regards to my other concern of snapshot growth and the reality of regular snapshot reversion, he also clarifies the absolutely vital point in all of this, which I didn’t do a very good job of in my initial post – every environment will differ. Although I still believe the place I work is fairly typical of any large enterprise at this point in time, the absolute best thing for you to do in your shop is test it and see what the business are willing to except in terms of rebuiilds or investment in other technologies such as app virtualisation and profile management. They may or may not offset any storage cost reductions, again every place will differ.

ThinApp Blog – would you like a glass of water to help swallow that foot?

December 4, 2008

I’m going to try and resist the urge to make this post another ‘effenheimer’ (as Mr Boche might say 🙂 but my mind boggles as to WTF the ThinApp team were thinking when they made this post. Way to call out a major shortcoming of your own product guys! To be honest, I’m completely amazed that VMware don’t support their own client as a ThinApp Package. Say what you will about Microsoft, but you gotta respect their ‘eat our own dogfood’ mentality. To my knowledge, if you encounter an issue with any Microsoft client based app that is delivered via App-V, they will support you to the hilt.

Now that i’ve passed the Planet v12n summary wordcount, I can give in to my temptation and start dropping the F bombs, because I’m mad. The VI client is a fairly typical .NET based app. If VMware themselves don’t support ThinApp’ing it, how the fuck do they expect other ISV’s with .NET based products to support ThinApp’ing their apps? Imagine if VMware said that running vCenter in a guest wasn’t supported – what kind of message would that send about machine virtualisation! Adding to the embarrassment, it seems that ThinApp’ing the .NET Framework itself is no dramas!!!

It’s laughable that a company would spend so much time and money on marketing efforts like renaming products mid-lifecycle, but let stuff like this slip by the wayside. Let’s hope this is fixed for the next version of VI.