VM /ETC

Posts Tagged ‘vdm’

You’ve probably already heard about VMware’s open source VDI client. VMware’s official announcement for the VMware View Open Client was released on February 4. Touted as the next step for creating a universal client to be used on any device from anywhere, VMware releasing the client as open source enables technology partners to start to fufill the vision. In VMware’s words:

“Now, VMware is providing VMware View Open Client for partners, enabling them to use VMware View source code to optimize their products to deliver rich, personalized virtual desktops to users. In addition, partners will be able to use the source code to help accelerate the development and delivery of solutions for enterprises to provision and manage thousands of virtual desktops simply, securely and at substantially lower operating costs.”

What I find most interesting is that Linux systems now have a installable VDI client. Unless I am mistaken, previously a web browser was the only way a connection to a virtual desktop could be made from Linux. Not only does this increase the functionality and features, Read the rest of this entry »

John Troyer has announced that the VMware website has been updated to reflect new product line names first introduced back in September at VMworld 2008. In the VMTN post Do they smell as sweet? New product line names: vCenter, View, John explains that the VirtualCenter and VDM products have are now referred to as vCenter and VMware View. Several VC add ons such as Update Manager and Converter are included along with Site Recovery Manager (SRM), Lab Manager, Lifecycle Manager, and even the file system VMFS now have slightly new names.

John provides a complete list of all products impacted by the name change which I have copied here. Read the rest of this entry »

Look for a new VMware KB article in the near future for this VMware VDM error.

I helped implement a VDI solution for a customer that ended up revealing an issue with VMware Desktop Manager (VDM) 2.1 and the resource pools of an ESX Cluster. The explanation of the problem to me was that the VDI desktops auto-deployed via persistent VDM pools were out of sync with the ESX resource pools they were members of, and therefore new VDI desktops could not be cloned by VDM. That’s a little confusing I know, so I’ll try to explain it better by providing the sequence of implementation steps that resulted in the issue.

Here’s how it happened. Read the rest of this entry »