At the gym this morning, we had a lively conversation about applications and virtualization. The other person, a software rep from Lawson, told me he was often asked if his application was VMware compliant. My customers seem to have many questions on what can be virtualized and what cannot. I recently read an article about this subject. The question what applications cannot be virtualized, not want can.
Here is a set of criterion that might help:
1. Applications that install and rely on a system-level driver, i.e. an application that installs a print driver or a USB device driver. Some applications may allow for the drivers to be installed independent of the other components of the application. As a work around for this scenario, the driver portion of this application could be installed locally on the client system, allowing the other components of the application to be virtualized.
2. Applications that install boot-time services.
3. Applications that use COM+.
4. MAPI virtualization
5. COM DLL surrogate virtualization, i.e. DLL’s that run in Dllhost.exe.
6. Applications with licensing enforcement tied to machine, e.g. the license is tied to the system’s MAC address.
That is about it. I hope this will help you.
Please can you give us pointers to the original article?
On the points you list:
1. The problem is just that the VM can't see the hardware?
For USB, I've seen a USB--TCP/IP 'bridge' recommended, btw.
2. My VMs happily run rc.local (Linux) and Windows Services at boot;
this isn't what you mean, though?
3--5. Again, can you be more specific, please?
6. You can set the MAC for VMware and for Xen, and I've happily
used that for licensing.
My main "problems" have been reduced memory and disk I/O performance,
compared to a physical machine; but that's hardly a surprise ;-)
Also, "VMware ESX Server: Advanced Technical Design Guide" is a little
dated (2.5.3 ?) and riddled with typos, but still has *lots* of good
info.
Posted by Tony Heskett on April 14, 2008 at 04:01 AM CDT #