Use PowerShell to disconnect the CDROMs from all VMs in vCenter

Recently I was moving all VMs from one NFS datastore to another so we could destroy the old volume. Storage vMotion took care of this for the most part, but even after moving the files, vCenter still showed that the VMs were using the old datastore. It turned out this was due to the VMs having mounted ISOs on that datastore. The solution was to eject/unmount the CDrom, but I didn’t want to do “Edit Settings…” and manually remove the CDrom for 200+ VMs.

I found this page which shows how to do almost exactly what I wanted via PowerShell. We’re using the vCenter Server Appliance though, which runs Linux, so I wasn’t sure how to run PowerShell stuff. But that was solved easily enough by installing VMWare’s PowerCLI package on my Windows desktop and connecting to the vCenter remotely:

PS C:usersevandocuments> Connect-VIServer vcenter.example.com

PS C:usersevandocuments> Get-Datacenter -name "Primary Datacenter" | Get-VM | Get-CDDrive | Set-CDDrive -Connected $false -NoMedia


Confirm
Are you sure you want to perform this action?
Performing operation "Setting Connected: False, NoMedia: True." on Target "CD/DVD drive 1".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y

Connect-VIServer pops up a username/password box where you put in your creds. The next command disconnects the cdrom for every VM in the “Primary Datacenter” datacenter in vCenter. I haven’t tried it but I think you can use different containers to scope the command however you want (cluster, resource pool, folder, etc). See here for other “location” options.

Advertisements

VMWare Tools Compatibility Matrix

Question: If I install the latest version of VMWare Tools on a guest, what kind of compatibility do I get when I vMotion to an older version of ESX? In other words, is VMware Tools backwards compatible with older versions of ESX/ESXi?

Answer: Yes, it’s backwards compatible. From this tool:

vmware-tools-compat

VMWare 5’s new licensing model.

After reading up on the new VMware licensing&pricing model I understand the uproar. Limiting vRAM is a reasonable constraint, but 32GB per socket for Enterprise? 48 GB for “Enterprise Plus”? If you have a dual CPU server with 144 GB (easily configurable last year), with 4.1 you’d only need 2 enterprise licenses to use all 144 GB, since in 4.1 an “Enterprise” license covered 1 CPU (up to 6 cores) and up to 256 GB memory on the host.

But with 5.0 you’ll either have to buy 5 Enterprise licenses (160 GB) or 3 Enterprise Plus licenses (144 GB) just to use the full 144 GB. I guess VMware has done away with memory overcommit as a selling point? They used to tell us it was recommended to go up to 2:1 so we could safely put ~140 GB of VMs on a 72 GB machine – with the new model that’s completely gone.

To put it in monetary terms, on the machine with 144 GB ram from above, the cost for 4.1 would be $2875 * 2 = $5750. To stick with Enterprise it would be $2875 * 5 = $14,375, or $3495 * 3 = $10,485. A gigantic price jump. I haven’t read up on any features of vSphere 5, but I don’t think any feature can make up for at minimum nearly doubling the cost, with loss of a major selling point (memory overcommit). I mean, you can still overcommit as long as you’re willing to pay for the overcommitted memory. Also, the above numbers are per-host, so if you’ve got a 5-host cluster you’re looking at a $25,000 price hike.

VMWare has long been one of my favorite products, but this is making me consider alternatives. Almost 100% of the feedback I’ve read about this change has been negative. Seems like a huge mistake on VMware’s part.

Migrating vCenter 4.0 to 4.1 (part 1)

When vSphere 4.1 was released earlier this year, I was mildly excited. Our ESX servers are still running 4.0.0 and I had been planning to upgrade to 4.0u1 for a while. When 4.1 came out it seemed to have vindicated my procrastination: now I could just upgrade to 4.1 and take advantage of whatever new features there were (I read something about memory compression… whatever).
Continue reading “Migrating vCenter 4.0 to 4.1 (part 1)”

vCenter: Error parsing the server "(server IP)" "clients.xml" file

I got the above error today after running Windows Update on my XP VM a few days ago. A quick search showed that the error is caused by a Microsoft update to the .NET framework. To resolve it, remove update KB980773 (Add/Remove programs, make sure “Show Updates” is checked; KB980773 is under “Microsoft .NET Framework 2.0 Service Pack 2”). I removed it and was able to log in without problems.

References:

Edit 10/22/2010: You can also resolve this by upgrading your vCenter client to 4.1, which I recently did. 4.1 is available on vmware.com.

vCenter: Error parsing the server “(server IP)” “clients.xml” file

I got the above error today after running Windows Update on my XP VM a few days ago. A quick search showed that the error is caused by a Microsoft update to the .NET framework. To resolve it, remove update KB980773 (Add/Remove programs, make sure “Show Updates” is checked; KB980773 is under “Microsoft .NET Framework 2.0 Service Pack 2”). I removed it and was able to log in without problems.

References:

Edit 10/22/2010: You can also resolve this by upgrading your vCenter client to 4.1, which I recently did. 4.1 is available on vmware.com.