How do you determine the version of FlexNet used by a vendor daemon?

The FLEXnet licensing framework is designed to limit the use of software to legitimately paying customers. Instead of achieving this goal, it punishes and annoys legitimate buyers while making it easy for cracking teams to defeat their software protections. Have you written a fake vendor daemon that always responds with "LICENSE AVAILABLE"? Congratulations, you've cracked every piece of software protected by FLEXnet!

One of my peeves with FLEXnet licensing was that not all vendor daemons were created equally. When a software vendor wants to protect their software with FLEXnet, they create a vendor daemon using the FLEXnet framework. This vendor daemon contains the business logic of license availability: it reads the license file, figures out whether you're entitled to a license, and gives the yay/nay. As Acresso try to clamp down on cracks, new versions of the FLEXnet framework are released with new features. If a vendor is on the ball, they'll update their vendor daemon. Fortunately for software pirates and cracking teams, most vendors aren't. Unfortunately for legitimate paying users, not understanding what version of the FLEXnet licensing framework a particular vendor daemon was compiled for can result in mysterious errors.

Example: the PRIMARY_IS_MASTER directive (which forces the first FLEXnet server in a triad to be the active node) was introduced in FlexNet 10.8. If you try to use this directive in a license file for Autodesk vendor daemon version 9.2.2.0, the license server would crash with an incredibly informative error message like "Error: there is an error. Refer to error description (Description: Error Occurred)." HELPFUL!

So, how do you determine the version of FlexNet used by a vendor daemon?

1. In the LMTOOLS application, click the Utilities tab then click the Browse button.
   
   
   
2. Select the vendor daemon executable then click Open.
   
3. Click Find Version.
   
4. Text will appear in the status window. The version is the number directly after FLEXnet Licensing.
   
   

Limit number of element occurrences with DTD

Both DTD and XML Schema allow the restriction of how many times an element occurs. DTD has modifiers that allow the limiting of element occurrences: * ? and +. If you add any of these symbols to an element, the amount of times it can occur is restricted.

<!ELEMENT Computer (Disk?)> means the Disk element can occur zero or once.

<!ELEMENT Computer (Disk+)> means the Disk element can occur one or more times.

<!ELEMENT Computer (Disk*)> means the Disk element can occur zero or more times.

XML Schema allows you to achieve the same result with minOccurs and maxOccurs attributes. In the following example, the Disk element can occur a minimum of once and a maximum of three times.


<xs:element name="Disk" type="xs:string" minOccurs="1" maxOccurs="3"/>

Can we perform the same restriction in DTD? It's messy, but possible! Use the OR operator (|) to specify a choice between the amount of options.

<!ELEMENT DiskSection (Disk | (Disk,Disk) | (Disk,Disk,Disk))>

Of course, anything more than a few options and it becomes very messy!

Installing VMware vCenter Operations 1.0.0

Another day, another VMware acquisition! VMware vCenter Operations (aka vCops, vCops on the block) is VMware’s entry into the operations management market. Not content with providing the hypervisor, VMware have decided to enter the management space. If you have a virtualized environment with no existing management software, vCops is a no brainer. If you’ve got a small to medium environment with a monitoring system you’re not happy with, vCops is worth a look.
To install vCops, you’ll need the following prerequisites.

1. VMware vCenter Operations
   
   You can either download a free trial from VMware.com or ask your friendly VMware account manager. I recommend your account manager, because they give you VMware-branded goodies like lanyards and pencils.
   
2. IP address
   
   You’ll need an IP address on a network with connectivity to your ESX hosts. Don’t forget the subnet mask and default gateway too! Is that network a /24 or a /25, I can never remember…
   
3. The hostname of your vCenter
   
   vCops has no automatic vCenter discovery feature, so you’ll need to know the hostname of your vCenter. It’d be nice if VMware baked some auto-discovery magic into OVFs, but we can live without it.
   
4. Service account credentialsvCops requires an account to establish a connection to vCenter. If you don’t have a dedicated service account, you can use your vCenter service account.
   
5. License key
   
   A 60-day trial key is available on the vCops download page. If you don’t have a key, you can only go as far as installing the product. You will not be able to login.
   
6. A secure password
   
   Like all other vApps, you’ll need to set a local password.

Got everything you need? Alright, let’s install!

1. Extract the source media and place the VMware-vcops-1.0.0.0-373027_OVF10.ovf file on your desktop.
   
2. In the vCenter client, click File > Deploy OVF Template…
   
3. On the Source screen, select the OVF file then click Next.
   
   
   
4. On the OVF Template Details, confirm you have enough disk space then click Next.
   
   
   
5. Accept the End User License Agreement then click Next.
   
   
   
6. On the Name and Location screen, enter the hostname and select the location of the virtual machine then click Next. You can use the default name of VMware vCenter Operations or something that matches your corporate naming scheme.
   
    
7. On the Host/Cluster screen, select the host or cluster you want to run CapacityIQ on then click Next.
   
   
   
8. On the Datastore screen, select the datastore for the CapacityIQ VM then click Next.
   
   
   
9. In the Disk Format screen, select the type of disk provisioning you want then click Next. If you’re installing vCops as a trial, thin provisioned is okay.
   
   
10. On the Network Mapping screen, select the network you want vCops to be connected to, then click Next. The security profile is similar to vCenter (similar users, similar access requirements), so you’ll probably want to choose the same network as your vCenter server.
    
    
11. On the Ready to Complete screen, click Finish to deploy vCops.
    
    
12. Wait for vCops to finish deploying. This is the VMware equivalent of watching grass grow. Luckily, deployment is quick.
    
    
    
13. Click Close to complete.
    
    
14. Power on the VMware vCenter Operations VM.
    Interesting note: the underlying guest OS is that it is SUSE Linux Enterprise 11 (64-bit).
    
    
15. Open a console to the VM. You’ll see the server booting.
    
    Notice the last entry: "check if we are installed in a VMware machine”! Does VMware expect people try run vCops on Hyper-V?!
    
    
    
16. Time to configure! Use your arrow keys to select Configure Network then press Enter.
    
    
    
17. It’s time to configure vCops with an IP address.
    
    
    
18. When IP configuration is complete, return to the main menu.
    
    
    
19. Now select the time zone.
    
    
20. If you’re installing vCops, you’re probably not in the “Queensland – Holiday Islands” time zone, although you might wish you were.
    
    
    
21. After configuring the time zone, return to the main menu.
    
22. The console-based configuration is complete. You can now close the remote console.
    
23. Open a web browser and access the IP address of vCops. If you’ve forgotten what this is, you can always check vCenter. The vCops appliance has VMware Tools installed so the IP address is reported.
    
24. The certificate warning can be safely ignored. You’ll have the option of configuring a certificate from your own CA later.
    
    
25. At the vCops login page, login using the username admin and password admin.
    
    
    
26. You will be prompted to change the default password. Enter the old and new passwords then click Change.
    
    
    
27. At the prompt, click OK.
    
    
    
28. Now it’s time to register vCops with vCenter.
    
    Name: this is a label and can be anything.
    Host (IP): the IP address of your vCenter. Despite the label, using the hostname seems to work fine too.
    Registration user name: the username of the account used to register vCops with vCenter. This is a once-off requirement and won’t be saved.
    Registration password: whatever your password is, hopefully not your name.
    Collection user name: this is the service account saved by vCops that performs collection. If you want to create a dedicated service account for vCops, put the username here. If not, you can specify your vCenter service account.
    Collection password: hopefully not 1234.
    
    
    
    
29. Click Test. If everything is right, you’ll get the message
    
    The registration credentials are correct.
    The collection credentials are correct.
    
    
    
    If not, don’t despair. Scroll to the bottom of this blog post for some help on registration error messages.
    
30. Click Save. You should get the message
    
    Use the vSphere Client to connect to the registered vCenter Server system and assign a license for vCenter Operations Standard.
    
    
    
    We’ll do that, but first let’s poke around the vCops console!
    
31. The first tab is the Setup tab.
    
    This is self explanatory. If you want to change any vCenter connection details, you can do this by clicking on the Update or Unregister buttons.
    
    
    
    The second tab is SMTP.
    
    If you want to setup e-mail alerting, this is the place to do it.
    
    
    
    The Logs tab has the logs for the vApp components. You can generate support bundles here.
    
    
    
    The Status tab has some basic status messages. If you’re viewing this tab, you can say with 100% certainty that vCops VM is powered on.
    
    
    
    The Self tab contains a health view of the vCops vApp.
    
    
    
    The UI Settings tab contains UI settings, big surprise.
    
    
    
    Want to change the admin password? (a good idea because the default is admin/admin!) Do this on the Account tab.
    
    
    
    Want to get rid of the annoying self-signed certificate warnings? If your organization has a CA, this is the place to upload the certificate. You don’t seem to be able to generate a Certificate Signing Request (CSR) here though.
    
    
    
    Okay, that’s all the vCops tabs. But what about the OS Configuration link in the upper-right corner? Click it.
    
    It dumps you at another login screen. You can login using root and the password you configured in step 26.
    
    You can perform a guest restart or shutdown of the vCops appliance from the System tab.
    
    
    
    If you need to change the vCops time zone, you can perform that from the Time Zone screen.
    
    The Network Status screen has network status…
    
    …and you can change the IP address details from the Network Address screen
    
    Proxies can be configured from the Network Proxy screen
    
    And appliance upgrades can be performed in the Appliance Administration screen.
    
    Anyway, our work from the console is done. You can logout. Now, back to vCenter…
    
    
32. In vCenter, open the Plug-in Manager (Plug-ins > Manage Plug-ins)
    
33. In the Plug-in Manager, ensure that the vCenter Operations Standard plugin is enabled.
    
    
34. In vCenter, go to the VMware Licensing Manager.
    (Home > Administration > Licensing)
35. Click the Manage vSphere Licenses button
36. On the Add License Keys screen, paste the vCops license, add a description then click Add License Keys.
    Click Next to continue.
    
    
    
37. On the Assign Licenses screen, select vCenter Operations on the left hand side. On the right-hand side, click the vCenter Operations Standard radio button. When you activate the license, a green tick will appear in the action column.
    
    This step is important! Do not proceed unless you see the green tick! If you don’t do this, vCops will throw an ambiguous licensing error!
    
    On the Remove License Keys screen, click Next.
38. On the Confirm Changes screen, click Next to finish.
    
39. Now, back to your web browser! Enter the address of vCops and login using your vCenter credentials.
    
    
    
40. Done!
    
    (You can also access vCenter Operations through the Solutions and Applications screen in VMware – Home > Solutions and Applications > vCenter Operations Standard)
    
    

The installation is pretty difficult to screw up. Here are all the errors I was able to generate.

• If you enter the wrong vCenter IP address, you’ll get the error
  
  vCenter Operations Standard cannot connect to the vCenter Server system to confirm the registration credentials. Check the status of the VMware VirtualCenter Server service.
  
  
  
  If you enter your username or password incorrectly, you’ll get the error
  
  The registration user name or password is incorrect.
  
  
• You’ll get a similar error if the collection user name or password is incorrect.
  
  The registration credentials are correct. The collection user name or password is incorrect.
  
  
• If you don’t activate the license properly, you’ll get an error message. If this occurs, make sure you add the license into the vSphere License Manager (step 36) AND assign the license (step 37). It’s easy to miss step 37.
  
  This product is unlicensed. Use a vSphere Client to connect to the vCenter Server and assign a license key.
  

Enjoy vCops!

FlexLM and Furious: Restricting FlexNet license usage

FlexNet licenses are expensive. Sometimes they can cost all your coffee money so it's no wonder you might want to restrict their usage. The FlexNet framework offers a horrific mechanism for restricting license check-out: the options file. Typically named license.opt, the options file is a configuration file that doesn't make sense to anybody.

A typical FlexNet license server folder containing an assortment
of files. The options file is labelled ‘4’. Depending on your region, this
may appear as IV or 四.

 

The options file allows you to restrict license check-out to authorized users (informally known as, "stopping those filthy students from other departments too cheap to buy their own darn AutoCAD licenses"). Can you restrict license check-outs to people in an LDAP or Active Directory group? No. You're restricted to lame methods like

1. Computer name - This might be useful if you want to authorize license checkout to computers in a specific computer lab or the nodes in a high-performance compute (HPC) cluster. If you're a university, your HPC cluster probably consists of over-clocked Celerons in a datacentre. And if you’re a university, your datacentre is probably a broom closet with an Apple sticker on it.
   
   
2. User name - If you include the line INCLUDE matlab USER paul, I will be able to check-out a MATLAB license for my Donald Trump popularity modelling project. But what if I login from a personal laptop where my user account is DoctorPaulMedicineMan? License check-out denied! And did I mention FlexNet treats usernames as case sensitive? If I login as PAUL or even Paul I'll get the same error: check-out denied!
   
   
3. IP address - this is useful in approximately 0% of circumstances. If your users use DHCP, it's useless. If your users VPN in, they're assigned a VPN address which is useless unless you want to give access to everybody who VPNs in (in which case, you're useless). If your desktops use static IP addresses, you've probably got bigger problems than restricting license checkouts.
   
   
4. Subnet - this would be useful if the programmers at Flexera knew how to subnet. In the magical FlexNet world (I'm not sure how to get there but I think it involves being at the Flexera offices and eating lots of mushrooms) there is no such thing as CIDR. To allow all the users in 172.16.0.1/24 access to the AutoCAD license, you simply include the line INCLUDE autocad INTERNET 172.16.0.* Simply place the asterisk in the subnet octet you want to permit! Awesome! Now, what do you do if it's a /25 and the next subnet is full of hungry AutoCAD who will consume all your licenses like piranhas with humans in a villain's lair?
   
   
   
   Piranhas can be restricted using an options files.
    
5. Display - you can restrict the check-out of licenses to a /dev/tty or Windows Remote Desktop client name. This was last used when tested in 1987 by a Highland Software engineer and the FBI currently offer a $25 million reward for any tips leading to proof this feature is used.
   
   
6. Project - check-out is restricted to users who have a environment variable set. This is unfathomably useless.

With all these useless mechanisms, how can I properly restrict license check-outs? I'm glad you asked.

1. Free for all! - if you're reading this blog post, you’re probably looking to restrict license usage so a free for all solution probably isn't acceptable in your organization.
   
   
2. License slave - designate somebody in your organization as a 'license slave'. Restrict license checkouts for controlled applications/features using an options file. If a user wants access to a feature, have the license slave add their username or hostname to the options file. To ensure they are always available to update the options file, simply handcuff them to their desk.
   
   
3. Leverage identity management! - Create a security group for each feature/application you want to restrict. For example, if you want to restrict AutoCAD check-outs, create a security group called Authorized AutoCAD Users Bagel. With some clever ETL skills, you can transform the contents of this security group into an options file! Could this be the topic of an upcoming blog post?!
   
   
4. Leverage directory services - The poor man's version of the above. Instead of using your identity management system to convert the contents of a security group into an options file, write a script to do it. Setup a scheduled task to run this script every second. Don't dare comment the script - this will allow somebody beside yourself to understand it which can only undermine your job security.

Thank you for reading. I'm unsure what my next licensing blog post will be on. Maybe alligators. Or that identity leverage thing.

 

Error "get unknown disk controller type" during a V2V or P2V

In 1927, Ivan Pavlov realized that a bell could be used to condition dogs to salivate. VMware have achieved similar conditioning with virtualization professionals and VMware Converter: a properly conditioned VCP will experience joy when shown a 100% status completed successfully image.

VCPs should exert caution when
viewing this image. Too late!

Conversely, when shown a status failed, the VMware evangelist will suffer VMware heartbreak, a condition characterised by keyboard banging and swearing.

The message nobody wants to see.

How do you start debugging a VMware Converter problem? Firstly, export the Converter log bundle and unzip it. Open the most recent vmware-converter-worker and vmware-converter-server logs. You can ignore nearly every other file: we’re only interested in the events surrounding the error (which are kept in the most recent logs).
Let’s look at vmware-converter-server-1. VMware Converter logs are like Windows logs except more verbose. The majority of messages are informational (read: useless). Instead of reading every event, look for the event that sticks out like a sore thumb.
[2011-02-10 13:15:24.117 04224 info 'App'] [task,373] [task-2] -- ERROR -- Convert: converter.fault.CloneFault (converter.fault.CloneFault) {
dynamicType = <unset>,
faultCause = (vmodl.MethodFault) null,
description = "unknown disk controller type",
msg = "",
}
The converter.fault.CloneFault is a generic error. The only useful information here is on the description line (highlighted in red) – unknown disk controller type. In this scenario, this error is probably enough to Google on but let’s drill down further. The vmware-converter-server logs only contain high-level error information. For more granular errors messages, we need to look at the vmware-converter-worker log.
[#4] [2011-02-10 13:14:06.509 04808 error 'task-4'] get unknown disk controller type
[#4] [2011-02-10 13:14:06.509 04808 error 'task-4'] hosted to managed disk clone failed: unknown disk controller type
[#4] [2011-02-10 13:14:06.509 04808 error 'task-4'] Disk clone failed with clone error unknown disk controller type
You can Google any of these errors to find the VMware KB article KB 1036719 - V2V conversion fails when using Paravirtual SCSI Controller. If you get this error message, you're probably trying to V2V a virtual machine with a paravirtualized SCSI adapter (aka PVSCSI). VMware have confirmed this as a bug, and they have a lame workaround: change the disk controller type to LSI Logic before the conversion.
“Before? BEFORE?! I’ve already done the V2V! This conversion took 57 hours! I need a resolution that doesn’t involve reconversion!”
I’m not sure why VMware recommended that workaround when a much easier alternative is available: changing the destination disk controller type. To do this, start the conversion wizard. On the Options screen, click the Devices Edit link.

Change the Disk controller option from Preserve source to SCSI LSI Logic. Click Next then proceed as normal.

For the more astute readers, you’ll notice the title of this blog post is incorrect. If you get this error message, it's because the source machine is a virtual and has a PVSCSI adapter. Therefore, the operation is a V2V and not a P2V. But I put 'P2V' in the title because it's a generic term for conversion and people seem to use the term interchangeably these days.

Moving a guest customization to another vCenter

Do you have multiple vCenters in your environment? Do you deploy VMs from different vCenters? Even if your vCenters are in in linked-mode and have shared storage containing your templates, you’ll still need to manually make guest customizations available on both vCenters. A pain, but easy to rectify. To move a single guest customization to another vCenter, perform the following tasks.

1. In the Customization Specifications Manager on the source vCenter, right-click on a customization then click Export.
2. Save the customization somewhere.
3. Copy this customization to the destination vCenter server
4. In the Customization Specifications Manager on the destination vCenter, right-click in the whitespace then click Import.
5. Select the customization XML file.
6. When the message “The Public key in the specification does not match the vCenter public key. Click OK to open the Customization Specification Wizard, reenter the password and continue the import.” appears, click OK.
7. Click Next until you reach the Administrator Password section.
8. At the Administrator Password section, re-enter the administrator password then click Next.
9. Click Next until you reach the Workgroup or Domain section.
10. If you want to join your VM to a domain, enter the relevant credentials then click Next.
11. Click Next until you reach the Ready to Complete section, then click Finish.

Now, that’s good for one guest customization. But what if you have a hundred? Use PowerShell. Arnim over at van-lieshout.com has a great guest customization export and import scripts.

Validating an XML document with an ISO-Schematron schema on OSX

Schema languages make sure your XML documents are valid. But not all schema languages are equal. ISO-Schematron is great but validation isn't as simple as right-clicking on your XML document in Eclipse and clicking Validate - Eclipse doesn't support ISO-Schematron natively!.

A good free and open-source XSLT and XQuery toolkit is Saxon. You can use the XSLT processor in Saxon to validate XML documents against ISO-Schematron schemas. There are three editions of Saxon - HE (Home Edition), PE (Professional Edition) and EE (Enterprise Edition). For validating the occasional document, Saxon-HE is fine. As of writing, the latest available is 9.3 which you can download here (saxonhe9-3-0-4j.zip).

Here are a few tips for first time Saxon users.

1. When you've finished downloading Saxon, don't unzip it with OSX's built in Archive Utility. There is a bug in Apple's Archive Utility that affects the way Java .jar files are handled (it "helpfully" extracts the contents of the .jar file). Unzip it with StuffIt Expander (available in the Apple App Store).
   
   
2. The command line usage of Saxon on OSX is slightly different to Windows. The command
   
   
   java -jar saxon9he.jar -o output.xsl -s mySchema.sch iso_svrl_for_xslt2.xsl
   
   
   will work in Windows but will throw an error in OSX ("Command line option -o requires a value"). You'll need your command slightly: add a colon after the -o operator and remove the space.
   
   
   java -jar saxon9he.jar -o:output.xsl -s:mySchema.sch iso_svrl_for_xslt2.xsl
   
   

Now, let's test an XML document against an ISO-Schematron schema.

Saxon doesn't simply spit out a 'Your XML document makes no sense' report. It takes two steps to validate an XML document against an ISO-Schematron schema. Step one involves three files.

1. iso_schematron_skeleton_for_saxon.xsl - this contains the ISO-Schematron schema definition/rules of war! This comes with Saxon.
2. iso_svrl_for_xslt2.xsl - SVRL is the Schematron Validation Report Language. It prepares your report and shows where you screwed up.
3. mySchema.sch - this is the schema you've written. It defines valid content.

We need to transform mySchematron.sch with iso_svrl_for_xslt2.xsl to create yet another XSL (let's call it output.xsl). To do this, execute the following command

java -jar saxon9he.jar -o:output.xsl -s:mySchema.sch iso_svrl_for_xslt2.xsl

If your schema was invalid, you'll get a Transformation failed: Run-time errors were reported message. Luckily, the error message is verbose and will tell you what line in your schema is invalid and why. If your schema was valid, you'll now have a output.xsl file.

Now, this output.xsl file you've generated is special. It contains a mashup of your schema with the SVRL. If you transform any XML document with the output.xsl file, you'll get an XML report detailing whether it is valid against your schema! How clever! Let's transform myXMLDocument.xml.

java -jar saxon9he.jar -o:whereDidIScrewUp.xml -s:myXMLDocument.xml output.xsl

In this case, whereDidIScrewUp.xml is the validation report of your XML document.

I hope this helps! I might write a Eclipse plugin if I get some time.

UPDATE: I've been beaten to the punch! Castle Systems have released Schematron-EP (Eclipse Plugin). I've yet to test it.

The virtual machine is running in a monitor mode that is incompatible for Fault Tolerance

And what is a monitor mode?

There are configuration issues for the Fault Tolerance operation. Refer to the errors and warnings list for details.

The virtual machine is running in a monitor mode that is incompatible for Fault Tolerance

Solution: turn the VM off, enable FT then power it on.

But that doesn’t answer: what is a monitor mode, and why do I have the wrong one? And why did I have to power the VM off to change the monitor mode?

In VMware, the Virtual Machine Monitor (VMM, or ‘monitor’) is the virtualization layer that presents virtual hardware to the guest. When virtualization technology was removed from the Roswell spacecraft by the VMware Corporation, Intel and AMD did not have virtualization hardware assist in their processors: early hypervisors ran entirely in software. The humans in Intel and AMD optimized their processors with virtualization-friendly features as they came to understand the beautiful alien technology. These processor optimizations (Intel VT-X/EPT, AMD-V/RVI) allowed VMware to optimize their monitor by offloading some virtualization features from software onto the CPU (in theory…)

The VMM has to operate in different modes according to the underlying capabilities of the processor. If the underlying CPU doesn’t have hardware MMU virtualization (hwMMU) support, the VMM cannot take advantage of it. Does this mean that if a CPU has hardware assist functionality, the VMM will always try to use it? No!

Under certain workloads, hardware assistance actually slows down the VM! And some features (like VMware FT) will not function if the monitor is using certain types of hardware assist. If you enable FT on your VM and the VM’s monitor mode is using hardware MMU virtualization, it will fail. Luckily, changing the monitor mode is just a matter of shutting the VM down, enabling FT (so the VMM knows not to use hwMMU), and powering the VM on.

For the most part, you don’t need to worry about monitor modes: the VMM chooses the best most depending on the operating system, your CPU and the VMware features required (FT, VMI). You can change the monitor mode in the the VM settings (VM > Edit Settings > Options > CPU/MMU Virtualization), but it’s not recommended.

An extensive list of default monitor modes for the different virtual machine configurations is available in VMware’s Virtual Machine Monitor Execution Modes in VMware vSphere™ 4.0 document.

Error “The server fault ‘SystemError’ had no message.” when working with a VM

Sometimes when you convert a template to a VM it becomes untouchable. When you edit the settings of an untouchable VM, the following error message appears.

The server fault ‘SystemError’ had no message.
Call "PropertyCollector.RetrieveContents" for object "propertyCollector" on vCenter Server "myVMwareServer.eight02.com" failed.
Useful eh? Luckily, fixing the problem is easy: just unregister and register the VM. To do that, perform the following tasks.

1. Make a note of the datastore that contains the untouchable VM.
2. Unregister the VM from the inventory.
   (right-click on the VM then click Remove from Inventory)
3. Open the datastore and subfolder containing the untouchable VM.
4. Register the VMs .VMX file.
   (right-click on the .VMX file then click ‘Add to Inventory’).

Done! The thing I don’t like about this error is it isn’t reproducible. Ah well, hopefully it is fixed in the Adobe Flex vSphere 5 client.