virtualization.info

NetApp just released a very interesting 38-pages paper comparing storage protocols performance in VMware vSphere 4.0 and VI 3.5 environments with Rackable S44 servers and FAS3170 arrays.

The paper, titled VMware vSphere and ESX 3.5 Multiprotocol Performance Comparison Using FC, iSCSI, and NFS, highlights a significant performance improvement in vSphere, mostly for iSCSI and NFS, since both have Jumbo Frame support.

The document also includes an comparison between 4GB FC, 1 Gigabit Ethernet and 10 Gigabit Ethernet, in terms of host CPU utilization and latency, which is worth a look.

Thanks to Yellow Bricks for the news.

Labels: Benchmarks, NetApp, Papers, Tech, VMware

In July VMware released a must-read 51-pages paper that is definitively worth a read: Performance Troubleshooting for VMware vSphere 4 and ESX 4.0.

The document, which is continuously updated, doesn’t just describe all the aspect of the product (CPU, memory, storage and network) that should be checked to troubleshoot performance. It also provides a much needed troubleshooting methodology:

Labels: Benchmarks, Papers, Tech, VMware

In June 2007 a couple of brave virtualization experts published one of the most wanted trick for VMware: how to run VMware ESX 3.x on a VMware Workstation 6.0 virtual machine.

Now Xtravirt, the consulting company that sold its tools to PHD Virtual (formerly PHD Technologies), is back on the topic and releases new paper to run VMware ESX 3.5 or ESXi on a VMware Server 2.0 installation.

The trick is to change some settings in the virtual BIOS of the Server VM along with adding the usual configuration parameters in the VM configuration.

Considering that both Server 2.0 and ESXi are free this is going to be an instant classic.

Labels: Tech, VMware

After the precious article about how Microsoft IT department internally uses Hyper-V, the TechNet library exposes another key resource: a list of all possible errors returned by Hyper-V.

The troubleshooting guide, called Hyper-V Health Model by Microsoft, is still a draft (last update was on April 7) but it’s already very detailed.
It divides the events and errors in five categories:

• Services
• Virtual Machines
• Virtual Network Switch
• Hypervisor
• Authorization manager (AzMan) Store

Each section has sub-categories with tens of event IDs. Each event ID has a list of actions to resolve the issue and to verify that everything is properly working.

Because Hyper-V 2.0 is not out yet, it’s safe to assume that this Health Model is only related to the first release of the hypervisor.
It’s surprising that Microsoft published it only now, and that the guide is still in draft.

Nonetheless, if you manage Hyper-V, this is one of the best resources available at the moment.

Thanks to HyperVoria for the news.

Labels: Microsoft, Tech

Who better than a virtualization vendor to show a successful case study to convince prospects to buy?

In May 2008 Microsoft published some details about how it’s using Hyper-V to serve MSDN and TechNet IIS7 web front-ends.

Nor VMware neither Citrix or other vendors ever published any information about their in-house implementations.
Anyway juicy additional details recently emerged about both the Microsoft and the VMware data centers.

How Microsoft is really using Hyper-V

The MSDN and TechNet case studies were interesting but lacked many details. A new document published in January 2009 on the TechNet library now tells a much clever (and in some cases concerning) story:

As early as September 2004, Microsoft IT calculated that the average CPU utilization for servers in data centers and managed lab environments was less than 10 percent, and continuing to decrease.

The virtualization goals are set very high for Microsoft IT, which has deployed more than 3,500 virtual machines. By June 2009, Microsoft IT plans to have 50 percent of all server instances running on virtual machines. With Windows Server 2008 Hyper-V, the expectation is that at least 80 percent of new server orders will be deployed as virtual machines.

…

As Microsoft IT developed standards for which physical machines to virtualize, it identified many lab and development servers with very low utilization and availability requirements. Because of the lower expectations, Microsoft IT now is deploying the lab and development virtual servers with four processor sockets, 16 to 24 processor cores, and up to 64 gigabytes (GB) of random access memory (RAM). These servers can host a large number of virtual machines, averaging 10.4 virtual machines per host machine.

As Microsoft IT developed its expertise in deploying virtual machines, and especially with the performance improvements available with Windows Server 2008 Hyper-V, it has increasingly moved toward virtualization of production servers. Although many production servers still have low utilization, some have significantly higher performance requirements than the lab and development computers. For the production-server deployments, Microsoft IT is using servers with two processor sockets, 8 to 12 processor cores, and 32 GB of RAM.

…

On average, the host servers with eight processors and 32 GB of RAM are hosting 5.7 virtual machines in the production environment.

…

Microsoft IT configures all virtual machine hosts to use a SAN to store the virtual machine configuration and hard disk files. The host computers connect to the SAN by using dual-path Fibre Channel host bus adapters (HBAs). For production virtual servers, the SAN storage uses redundant array of independent disks (RAID) 0+1, whereas RAID 5 is used for lab and development virtual machine storage. Microsoft IT has chosen the RAID 0+1 configuration for the production servers because it provides better performance, but it does consume more disks. Performance is not as critical in the lab environment, so Microsoft IT uses RAID5 because it uses fewer disks to store the virtual machines.

…

When Microsoft IT first deployed server virtualization, the goal was to use a shared storage model for the virtual machines. During the first iteration, Microsoft IT would create one or two large logical unit numbers (LUNs) on the SAN (100-plus GB) for each host computer and then deploy multiple virtual machines per LUN. In a typical scenario, Microsoft IT gave the customer a 50-GB drive C and a 20-GB drive D. Because both drives were dynamic virtual disks, the actual space used on the LUN was much less than the maximum size.

However, over time, the dynamic disks grew as the customers stored data on the virtual servers, and just two or three virtual machines could fill an entire LUN. This became a significant management issue for Microsoft IT, which had to track all LUNs for space availability and then move virtual machines before all space was utilized.

To address this issue and to enable failover clustering for the virtual machines, Microsoft IT next adopted a model of configuring just a single virtual machine per LUN. With this model, a LUN with 30 to 50 GB was dedicated to each virtual machine, with the option to give the virtual machines more space as required.

Microsoft IT has avoided using disk mount points, so the limiting factor for the number of virtual machines deployed on a host became the number of available drive letters on the host computers. In most cases, this meant not deploying more than 23 virtual machines on a host.

…

• Microsoft IT has achieved 99.95 percent availability for virtual machines running on Microsoft Virtual Server 2005 R2, and it anticipates that the availability will increase for virtual machines running on Hyper-V. Very few applications that have been deployed as virtual machines require a higher availability level.
• With Windows Server 2008 failover clustering, an administrator must store each virtual machine on an individual LUN. Because an administrator must provide all cluster nodes with access to the same shared storage by using the same drive letters, 23 is the maximum number of virtual machines that can run in a failover cluster. Microsoft IT could work around this limitation by using mount points and virtual machine groupings, but it considers this configuration too complex to administer. Because of this limitation, Microsoft IT has adopted a standard of using only three nodes in a cluster, with the cluster configured to tolerate one node's failure.
• When virtual machines fail over in a Windows Server 2008 failover cluster, the cluster service with Hyper-V must save the virtual machine state, transfer the control of the shared storage to another cluster node, and restart the virtual machine from the saved state. Although this process takes only a few seconds, the virtual machine still is offline for that brief period. If an administrator has to restart all hosts in the failover cluster because of a security update installation, the virtual machines in the cluster have to be taken offline more than once. Therefore, Microsoft IT determined that highly available virtual machines could have more downtime than virtual machines deployed on stand-alone servers in the case of simple planned downtimes for host maintenance, such as applying software updates.
• Because of the required brief outage every time a virtual machine is moved from one host to another, Microsoft IT found that coordinating the server update processes with virtual machine owners was difficult. Because one physical host could contain several virtual machines, Microsoft IT had to communicate with each of the virtual machine owners and coordinate host server maintenance with virtual machine maintenance.

Because of these issues, Microsoft IT has not deployed failover clustering as the default standard for virtual machines. Microsoft IT has deployed several three-node clusters and does provide this service for virtual machines running critical workloads. One of the places where Microsoft IT is using failover clustering for virtual machines is in some branch offices that do not have 24-hour support staff on site. In a data center where administrators always are available to react to host downtime, Microsoft IT has minimized the use of Hyper-V clustering…

The whole article is priceless and its read is highly recommended (thanks to Vinternals for the link).
For the lazy ones Microsoft even published a webcast about this internal case study. The presenter is David Lef, a Microsoft IT Technology Architect at Microsoft.

How VMware is really using ESX

As we said, despite its leadership, VMware never revealed how it’s using ESX and other products internally.
The fist time ever that the company disclosed details about its virtual infrastructure was in September 2008 at VMworld US. A refreshed presentation (DC35) was shown during the VMworld Europe 2009 by Tayloe Stansbury, the company CIO.

• VMware has an internal VDI deployment of over 550 users, including members of most departments.
  The client configuration includes Wyse V10 Thin Clients, Dell 24” monitors (configured at 1920x1200 pixels, 15bit resolution), keyboard and mouse.
  The server configuration runs on HP c7000 blade systems, EMC Clariion CX3-80 storage and Cisco 3020s switch modules for the HP blades.
  The entire infrastructure is powered by VMware Virtual Desktop Manager (VDM) 2.1 for US and View 3.0 for Europe.
• VMware has an internal virtualized mail server deployment serving 7800 mailboxes.
  The entire infrastructure is powered by 29 virtual machines (split in two data centers) running Microsoft Exchange 2007 Enterprise Edition. 22 of them are just for the mailboxes, the other 7 work as Client Access Servers (CAS).
• VMware virtualizes its entire ERP infrastructure except Oracle Real Application Clusters (RAC). 
• 97% of the company servers are virtualized across one Tier 4 and two Tier 2 data centers.
  Just two applications are missing (one is Oracle RAC).
  EMC DMX4 is used as the storage backend of choice for mission-critical applications, otherwise EMC CX3-80 is the choice.
  The front-end servers of choice are HP c7000 blades everywhere.
• The average consolidation ration is 10:1 for server and 64:1 for VDI desktops
• Each administrator manages an average of 145 virtual machines.

For the ones that cannot access the VMworld presentations (it requires a yearly subscription) VMware published a webcast about this internal case study.

Labels: Microsoft, Tech, VMware

In June 2008 Microsoft published an important document for all the customers that are evaluating and adopting its hypervisor: the Performance Tuning Guidelines for Windows Server 2008.

The document contains a section dedicated to Hyper-V and while most of the suggestions included in this whitepaper are just common sense or recap of the product features, there are some hidden treasures:

Correct Memory Sizing

…

A good standard for the memory overhead of each VM is 32 MB for the first 1 GB of virtual RAM plus another 8 MB for each additional GB of virtual RAM. This should be factored in the calculations of how many VMs to host on a physical server. The memory overhead varies depending on the actual load and amount of memory that is assigned to each VM.

…

Disabling File Last Access Time Check

Windows Server 2003 and earlier Windows operating systems update the last-accessed time of a file when applications open, read, or write to the file. This increases the number of disk I/Os, which further increases the CPU overhead of virtualization. If applications do not use the last-accessed time on a server, system administrators should consider setting this registry key to disable these updates.

NTFSDisableLastAccessUpdate

HKLM\System\CurrentControlSet\Control\FileSystem\      (REG_DWORD)

By default, both Windows Vista and Windows Server 2008 disable the last-access time updates.

…

I/O Balancers Control

The virtualization stack balances storage I/O streams from different VMs so that each VM has similar I/O response times when the system’s I/O bandwidth is saturated. The following registry keys can be used to adjust the balancing algorithm, but the virtualization stack tries to fully use the I/O device’s throughput while providing reasonable balance. The first path should be used for storage scenarios, and the second path should be used for networking scenarios:

HKLM\System\CurrentControlSet\Services\StorVsp\<Key> = (REG_DWORD)

HKLM\System\CurrentControlSet\Services\VmSwitch\<Key> = (REG_DWORD)

Both storage and networking have three registry keys at the preceding StorVsp and VmSwitch paths, respectively. Each value is a DWORD and operates as follows. We do not recommend this advanced tuning option unless you have a specific reason to use it. Note that these registry keys might be removed in future releases:

• IOBalance_Enabled
  The balancer is enabled when set to a nonzero value and disabled when set to 0. The default is enabled for storage and disabled for networking. Enabling the balancing for networking can add significant CPU overhead in some scenarios.
• IOBalance_KeepHwBusyLatencyTarget_Microseconds
  This controls how much work, represented by a latency value, the balancer allows to be issued to the hardware before throttling to provide better balance. The default is 83 ms for storage and 2 ms for networking. Lowering this value can improve balance but will reduce some throughput. Lowering it too much significantly affects overall throughput. Storage systems with high throughput and high latencies can show added overall throughput with a higher value for this parameter.
• IOBalance_AllowedPercentOverheadDueToFlowSwitching
  This controls how much work the balancer issues from a VM before switching to another VM. This setting is primarily for storage where finely interleaving I/Os from different VMs can increase the number of disk seeks. The default is 8 percent for both storage and networking.

…

Interrupt Affinity

Under certain workloads, binding the device interrupts for a single network adapter to a single logical processor can improve performance for Hyper‑V. We recommend this advanced tuning only to address specific problems in fully using network bandwidth. System administrators can use the IntPolicy tool to bind device interrupts to specific processors.

…

Labels: Microsoft, Tech

One of the biggest limitation of Virtual Server 2005 was the impossibility to backup the running virtual machines with NTBackup.

When Microsoft moved to Windows Server 2008 and Hyper-V this limitation was finally removed, but the capability is not exactly out of the box.

To achieve the goal customers must manually create some new keys in the Windows Registry so that the Hyper-V Volume Shadow Service (VSS) writer can interact with the new Windows Server Backup (WSB).

The configuration also has some serious limitations:

1. WSB only supports volume based backups: if the VM configuration file and the actual virtual hard drive (.VHD) are stored in different volumes, all volumes must be selected.
   Conversely, when performing a recovery from backup, the entire volume or volumes must be restored.
2. Live backup is not supported for those VMs that have dynamic disks. In such case only offline backups can be performed.
3. If the VM has more than one snapshot the restore will fail (there’s a workaround for this)
4. Live backup is unavailable for those guest OSes that don’t support VSS, like Windows 2000 or XP, as well as those guest OSes that don’t have the Hyper-V Integration Services installed.
   In such cases WSB will put the VM in a saved state, backup the snapshot, and finally restore the VM.

Of course Microsoft has all the interest to keep these limitations so that most demanding customers will be forced to look at the new Data Protection Manager 2007 SP1.

Labels: Microsoft, Tech

Did you see the new VMware video about vCenter Site Recovery Manager (SRM) and would like to try it firsthand?
You only have three choices:

• Configure your own lab
• Rent the proper enterprise equipment at our own virtualization.info Rent-A-Lab
• Setup the whole thing in a consumer box

The last scenario may sound a little hard to realize (and certainly not the best one for some serious evaluation) but it can be done: VMware published an official 20-pages guide describing all the steps to configure a two-sites environment with SRM in a single consumer box.

To achieve the (magic) goal VMware suggests to use a 64-bit laptop with Intel VT and at least 3GB RAM, VMware Workstation 6.5, LeftHand Network virtual SAN, and of course VI 3.5 plus SRM 1.0.

Labels: Tech, VMware

Richard Garsthagen, Senior Evangelist at VMware, just published a new video featuring a live demo of vCenter Site Recover Manager (SRM).

The video is 15 minutes long and really worth a look if you are not familiar with the new VMware disaster recovery solution.

You can see it on a new website that virtualization.info is building (still in very beta): www.virtualization.tv

Labels: Tech, VMware

In May Citrix released its first fully-featured VDI platform combining together a hypervisor, XenServer, a connection broker, Desktop Deliver Controller (DDC), an OS streaming solution, Provisioning Server, its blockbuster presentation/application virtualization & streaming plaform, XenApp (formerly Presentation Server) and a bunch of other applications.

Only the most skilled Citrix customers know that this rich suite, called XenDesktop, has a limitation: the remote desktop protocol it uses (internally called PortICA) it’s not exactly the same ICA that powers XenApp.

The reason behind this difference is that the ICA protocol is built on top of the Microsoft Terminal Server platform that is missing in the Windows XP and Vista guest operating systems that populate VDI environments.

Citrix has rebuilt many of the features in the new PortICA and it’s working to have the same feature-set across the two protocols. But for now there’s a gap.
Martin Maierhofer, Product Architect at Citrix, details the missing capabilities on his corporate blog:

• Kerberos SSPI: while a useful feature, this integrates deeply with the logon process, and this is one area where - you guessed it - XenApp and XenDesktop differ considerably. Moreover, for it to be really useful you will typically have to mark the computer that your end users connect to as "trusted for delegation" - and typically . While that may be ok for a relatively small number of well managed XenApp server, it's less clear that you'd want to do this for thousands of virtual desktops, where your users may have full admin rights. Morever, Windows XP doesn't support constrained delegation, which makes this a less attractive solution. Hence we decided to leave this aside for the initial release.
• SmartCards: this is a very important feature for a relatively small, but vocal target market. Again, from a technical point of view it is far from a straight port from XenApp. Having said that, it is a high priority item and we are working on delivering it as soon as possible.
• SpeedScreen: SpeedScreen is a term that refers to a large array of technologies that optimize the end user experience. The first version of XenDesktop shipped with support for the majority of SS features, including SS Browser Acceleration, SS Flash Acceleration, SS Image Acceleration, and SS Progressive Display. Now for the features that didn't make the cut: SS Multimedia Acceleration was unfortunately too late to make it into the first release, but we are well under way with it now. The situation is less clear with SS Zero Latency - XenDesktop already supports mouse click feedback, but keyboard type-ahead is a technology that is not terribly easy to set up, and can be tricky to get working with more recent applications that you would typically find on a virtual desktop. For now, we are assessing how we can best make this functionality available on XenDesktop.
• PDA Sync and Twain: again, these are fairly tied to the Terminal Services infrastructure on XenApp. Moreover, virtually all PDAs and scanners nowadays are USB devices, and we will tackle them in a more compatible and user-friendly manner through our upcoming USB remoting technology in XenDesktop.
• Shadowing: as I mentioned before, on XenApp this is based off Terminal Services capabilities that just aren't available to us in XenDesktop. XenDesktop Platinum comes with Citrix GotoAssist, which is a more than capable replacement for shadowing, or you can also use the built-in Remote Assistance feature built into Windows for a premise-based solution. We also have plans to support shadowing functionality in future.
• SmartAuditor: SmartAuditor is used by a relatively small customer segment, and thus wasn't among the highest priority items for a first XenDesktop release. There has been quite a lot of prep work for this already, and I am confident that we'll include this in one of the future XenDesktop releases.
• Audio on Vista: this is a bit tricky - Vista's audio architecture differs fundamentally from that used in Windows XP, and we need to completely re-implement the audio framework in PortICA to support Vista, which unfortunately has taken a bit longer than we'd hoped, but is nearing completion now. The good news is that we will be able to take advantage of this rework to integrate much better audio codecs in future.
• Perfmon Counters and User Experience Metrics: again lack of support for these metrics was due to resource constraints, and there are only minor technical difficulties to make them available on XenDesktop.

Labels: Citrix, Tech

By now the whole virtualization world should be aware that VMware took the big step of releasing its flagship hypervisor as a free product: ESXi 3.5.

Despite that, maybe not everybody knows that this free platform has some limitations compared to the fully-featured ESX 3.5.
To clarify the things VMware published a new knowledge base article with a valuable comparison matrix.

Please note that this table is only focused on the virtualization host capabilities and doesn’t consider all the features that VirtualCenter can bring in. This avoid any confusion that previous comparison (for example ESXi stand-alone vs ESX+VC) could imply.

Labels: Tech, VMware

In May Citrix released the second major version of its VDI solution XenDesktop.

The product is much more than a connection broker for virtual infrastructures as it includes a plethora of other Citrix products, from the Provisioning Server to the Access Gateway, passing through the GoToAssist.

The result is a feature-rich and powerful product but the side effect is that newcomers can be very confused trying to understand how the platform works.

To address the issue Citrix just released a lengthy slide deck detailing XenDesktop 2.0 architecture, exploring all the tiers used in different business cases.

The document is certainly not enough to fully get the potentials of this product but it’s good starting point.

Labels: Citrix, Tech

It’s not a secret that VMware loves the Microsoft Powershell scripting technology. And it’s not a secret that VMware loves to humiliate any Microsoft effort to compete with Hyper-V.

Merging together the two passions, Mike DiPetrillo, the now famous Special System Engineer of Industry Research and Competitive Analysis department at VMware, produced a script which brings the SCVMM Quick Migration feature to VMware VirtualCenter.

Microsoft Quick Migration isn’t comparable to VMware VMotion as the former implies some downtime when moving a virtual machine from a physical host to another, but some VMware customers may find it interesting because VMotion comes as an expensive option.

DiPetrillo assures that he’s not a professional script writer. Despite that he could build the feature with just 130 lines of Powershell code.
Maybe it’s just the powerful VMware Infrastructure Toolkit for Windows, maybe its just the powerful Powershell language, but the thing sounds very ironic here.

Of course this is not even near an official feature or tool and VMware doesn’t support it in any way.
Nonetheless the script is already popular among the community and some users already managed to improve it.

To demonstrate the capabilities of its VI PowerScripter (still in beta 2 at the moment) the new Swiss startup Icomasoft (see the virtualization.info coverage here) integrated the script into VirtualCenter and added a useful GUI to it:

Thanks to Duncan Epping for the screenshot.

Labels: Tech, VMware

I'm happy to annonce the first virtualization.info HowTo: Install Sun Solaris 10 inside VMware Workstation 5.5.

This is a very step-by-step guide (with screenshots) for configuring a virtual machine and installing on it Sun Solaris 10.

At the end you'll be able to run the virtual machine inside Workstation 5.5 or inside VMware Player 1.0, which is a free virtualization product. And soon with VMware Server 1.0.

Download it here.

Labels: Tech, VMware

• Hosted Client Solutions on VMware Workstation
• Hosted Client Solutions on Microsoft Virtual PC

Labels: Tech, VMware

Even on a 2 GB RAM workstation (as mine) VMware virtual machines can run slowly. Too slowly sometimes.

This can depend on a large amount of factors but we can reduce the number to 4 critical issues:

1. Antivirus real-time protection
   You probably run VMware Workstation on your everyday working computer, and you probably want to stay secure running an antivirus software.
   
   The most useful feature of any AV is the real-time protection, catching and monitoring I/O accesses of every process for suspicious activities. This feature can greatly impact on your VMs performances and should be fine-tuned for virtualization.
   
   So be sure to create an exclusion filter on your real-time protection settings for .vmdk (VMware virtual disk) and .vmem (VMware virtual memory) files. In this way countinous I/O operations on your virtual machines will not be hit by antivirus checking.
   
   Note: if you plan to run liveCD operating systems (like Knoppix) inside your VMs or simply often use CD images for installing new software, I highly recommend to exclude .iso files too from AV checking.
2. HostOS disk fragmentation
   A really performance hitter for virtual machines is a fragmented host OS disk.
   
   VMs virtual disks are very large (4 GBs at minimum on the average) and are created by default as non preallocated. In other words your virtual disk grow as you install more software on the guest OS till reaching your defined disk limit.
   If you use only one physical disk for everyday work and VMs storing, you probably will use space around a growing virtual disk, obliging your host OS to fragment virtual machines more and more.
   
   So be sure to:
   • Create a dedicated partition for virtual machines only
   • Create guest OSes virtual disks with Allocate all disk space now option
   • Schedule a daily defragmentation for your virtual machines directories (maybe at launch time or during the night)
3. Memory trimming
   Workstation checks which part of the guest OS virtual memory is not used and allocates it back to the host OS. This permits to have more concurrent virtual machines running but everytime the guest OS asks back for its memory it suffers a performance degradation.
   
   So, if you have enough free RAM for all planned concurrent VMs, be sure to disable memory trimming for guest OSes adding the following line to the virtual machine configuration (.vmx) file:
   
   MemTrimRate=0
   
   Note: Memory trimming can be disabled through GUI since Workstation 6.0.
4. Page sharing (quoted from VMware documentation)
   VMware uses a page sharing technique to allow guest memory pages with identical contents to be stored as a single copy-on-write page. Page sharing decreases host memory usage, but consumes system resources, potentially including I/O bandwidth.
   
   You may want to avoid this overhead for guests for which host memory is plentiful and I/O latency is important. To disable page sharing, add the following line to the virtual machine configuration (.vmx) file:
   
   sched.mem.pshare.enable=FALSE option

These suggestions will work well for every VMware Workstation 5.x and Player 1.x since both share same engine.

Labels: Tech, VMware

After exploring how to launch ISOs from an empty virtual machine with VMware Player, we can trying something harder: create a brand new virtual machine with the Player.

This shouldn't be possible since VMware Player only permits you to run precreated VMs, mainly because we miss an empty virtual HD (something .vmdk) where to install things. We just need to find one of them and the trick is done.

What I'm going to detail below isn't something extraordinary and maybe many readers of the previous post (or any moderately skilled VMware user) already tried.

The same results can be achieved by simply downloading VMware Workstation trial and creating a test virtual machine.

How to create new virtual machines

With the launch of VMware Player VMware also started distributing a free downloadable virtual machine called Browser Appliance.

Download it from VMware site and unpack it on your HD.

Then prepare ISOs for the operating system you are going to install inside our recycled VM.

Note: if you plan to produce an ISO from a physical CDrom (with tools like UltraISO or WinImage) be sure to dump the boot sector too.

Now follow my previous post about launching ISOs from VMware Player and produce your own .vmx configuration file mapping the prepared ISO on the virtual CDrom.

Finally grab the VMware Browser Appliance virtual machine configuration file (Browser-Appliance.vmx) and replace similar lines with ones from your .vmx configuration file.

You'll have a resulting .vmx file that maps an 800MB virtual HD (Browser-Appliance.vmdk) where you can install the operating system booting from your mapped ISO.

If this virtual HD is too small try to grab another freely available virtual machine at VMware Virtual Machine Center and repeat the process.

Update 1: Many readers reports me that a QEMU utility, called qemu-img, is able to create VMware .vmdk disks from scratch.

I tried and it works but I'm not sure if the tool breaks any VMware EULAs. If any VMware employee is reading please send me some details.

Update 2: After VMware Player release a huge amount of users created web and binary applications for automated production of virtual machines, circumventing Player limitations. I found the best one is EasyVMX!

Final note

VMware Workstation really worth the money it costs. And if you read my blog you really know how this is true.

Use this procedure just to experiment and then buy the product.

Labels: Tech, VMware