I was training last week with VMware View product. To be truthful, it’s not a product I’m especially enamored of....
I find its admin tool crude and limiting, although users don’t seem to mind it. I’m expecting/hoping for good things in the next release, not that I would know anything about that. I can’t get on the beta program despite having more vs after my name (vExpert, VCP, VCI, vImportant).
Anyway, grumbling aside - one of my students pitched a usage case to me and asked me if I thought VMware View could deliver. In the first instance you would want to recommend “Lab Manager” for this guy's usage case, but I know that a budget for yet-another-management-product-from-vmware would probably not be there. It was up to me to try to cobble something together. Here’s the usage case. He wants his developers to get a desktop, install stuff, and generally play around with the desktop. But then give them an easy way to reset the desktop back to clean state. At the moment they have vCenter access to use snapshots/revert to snapshot, but they aren’t keen on giving them access to vCenter. They want to do it via View. Of course, non-persistent pools could help in this case; they have a feature which allows you to delete, and create a new, virtual desktop at logoff. But I could see that rather than disconnecting one day, a developer would logout to find out their work was destroyed. I guess a bit of redirection and hardening could force them to store their stuff outside of the desktop, but my guy was trying to avoid bolting them down.
So I hit upon this idea:
- Create a persistent pool of desktops
- Let them power up and sysprep themselves
- Use PowerCLI to shut them all down
- Change the Disk Mode on the OS drive to independent mode with non-persistent
- Set the Desktop Pool to “Ensure VM is always powered on” and “Allow users to reset desktop”
This means if the developer in the virtual desktop had shutdown their desktop OR used the Reset Desktop option in the View menu, their desktop would be reset to its previous state
This works fine as a concept but falters in two places. If the developer did a restart of Windows with the NT Security dialog box, the View Agent didn’t appear to restart properly (I figured I could write a powershell script to handle that which would run within the developer's virtual desktop, the downside of which leaves me giving them access to vCenter, which I'm trying to avoid.
The second place it falters is in the use of non-persistent mode on a virtual disk. I was reading through the help file on the Set-HardDisk (which supports changing the disk mode of a VM) cmdlet when I came across this statement:
“Specifies the disk persistence mode. The valid values are: Persistent, NonPersistent, IndependentPersistent, IndependentNonPersistent, and Undoable. This parameter is supported only when the disk type is set to “rawVirtual” or “flat”. Note that the ‘NonPersistent’ and ‘Undoable’ persistence policies are deprecated and will be discontinued in future releases. Their usage is not recommended because they do not work with snapshots and are not supported on ESX 3.5 and higher.”
This was taken from a machine running the new PowerCLI 4.0 which is compatible with vSphere4.
The operative word is “deprecated”. It’s a special word used by VMware that you rarely hear from other vendors. I put up with their usage of the word “experimental”. Occasionally, VMware deprecated a feature. This is a rather artful way of saying “You know that feature you liked, understood, and wrote scripts and procedures for? Well, my friend, we're removing it.” Just like that. No consultation.
It’s not the first time I’ve come across this with VMware. For example, in ESX3.x.x the old ESX2.x.x command vmkpcidivy got deprecated because it was no longer relevant. Similarly, the functionality of esxcfg-vmhbadevs in ESX3.x.x got deprecated in ESX4.xx. in favor of another utility that provides much better functionality.
You see, I don’t have a problem with “deprecated” especially when a new method is better or the old method is simply irrelevant. Besides, we can all agree we don’t want software bloated out with old procedures/utilities/codes which are no longer needed. That would make you like other ISVs which will remain nameless!
But what irks me about it is the arbitrary nature of it. You never quite know when a feature might get deprecated on you (such as the shrink feature in VMware Tools). Often the deprecated process seems quite arbitrary, especially when it happens within a product release. If it happened between two major product releases that could be understandable/excusable. But when it happens within a product release occasionally, it feels a bit odd. Can you imagine the manufacturer of your car deprecating the wing mirrors of your car after you have bought it?
Clearly, vendors do reserve the right to discontinue models, but they don’t tend to remove features during the lifetime of a model. So model 3.0.2 of a car has wing mirrors, but in the 3.5 upgrade, in which they forced you to move up to keep your service plan, they deprecated it.
Anyway, back to my powershell. I decided to ignore the advice. I used:
get-vc virtualcenter4.vi4book.com –user administrator –password vmware
stop-vm -vm (get-vm -name devdesktop*) -confirm:$false
get-vm -name devdesktop* | Get-HardDisk | Set-HardDisk -Persistence IndepedentNonPersistent
In short, you can configure non-persistent mode on a virtual disk in the vSphere4 client, and you can do it with the PowerCLI. But if you use this feature you run the risk of being deprecated at some unspecified point in the future.
Anyway, what to say to my customer? Set non-persistent using PowerCLI, but beware of upgrades that could stop these scripts/function working in the future? Offering him snapshots powersHell scripts instead? (This is what I’ve done) Sell him a product (lab manager) he doesn’t desire or have a budget for?