In this Q&A, Serdar Yegulalp looks at the good (networking), the bad (built-in documentation tools) and the OK (virtual machines per server) aspects of Microsoft's virtualization offerings, particularly Microsoft Virtual Server. Besides publishing "The Windows 2000 Power Users Newsletter", Yegulalp answers IT pros' questions about Microsoft Virtual Server as Ask the Expert advisor for SearchServerVirtualization.com.
Does Microsoft have good physical-to-virtual (P2V) migration tools?
Serdar Yegulalp: Microsoft's own tools for converting live machines to VMs are really not very good, from what I've seen. They're clunky to use and require that you go through a multi-stage conversion process which interrupts work on the original server. That said, they're free -- and if you don't have much of a budget to work with, they may be the only game in town.
I've looked at some other migration solutions, such as LeoStream P>V Direct 3.0 and PlateSpin PowerConvert, which are a lot more seamless; but they're also that much more costly, and typically charge per system converted. If you can spend the money to use such tools, look into them.
How many virtual machines (VMs) can Microsoft Virtual Server support per physical server?
Yegualp: Microsoft's documentation for Virtual Server 2005 indicates that you can run a maximum of 64 virtual machines per physical server. However, that documentation notes that how many VMs you can run per server simultaneously depends on system resources, the amount of memory assigned to each virtual machine and the total memory available on the physical computer. Note that Virtual Server supports up to 3.6 GB of RAM per virtual machine.
IT pros are telling our editors that naming, locating and generally managing VMs is tough. Can VM documentation be handled using some tools in Microsoft Virtual Server?
Yegulalp: As far as I know, Virtual Server doesn't have any built-in mechanisms for documenting or describing the contents of VMs, aside from the name of the machine in question. One possible way to get around this is to invest in a product like Microsoft Operations Manager or one of its equivalents (i.e., NetIQ), and treat your virtual servers like any other collection of physical machines that need to have their assets tracked and allocated.
There should always be some kind of consistent labeling to make it possible to tell virtual and physical machines apart. It doesn't matter what it is, as long as it's internally consistent and self-documenting -- such as placing all the VMs and their controllers in a single domain, or just using the suffix "-VM" for each virtual machine's machine name.
One typical difference between tracking virtual and physical machines like this is that not every virtual machine may be online at the same time. For instance, let's say each of those instances has a slightly different software configuration and you're testing them out in rotation. So, if you have a given virtual machine that exists in five separate instances, each of those instances should be registered as a separate machine. This is one of those wrinkles in the way VMs work that is often overlooked.
Since Microsoft Virtual Server is only supported under Windows Server, which of these approaches to using it would be better:
- Build a 2003 box. Install nothing on it besides Virtual Server 2005, and then run my servers under it as VMs?
- Use the operating system as one of my application servers and run the VMs underneath it for the extra machines? If I can use the host server as an application server, is there a suggested way to run it?
Yegulalp: Both approaches are valid depending on what you're trying to accomplish. It's entirely possible to set up a system running Virtual Server and also have it running something like Microsof SQL Server (albeit with a much smaller memory footprint than you might have if it was running in a system where little else was present). Then, have the VMs talk to the SQL Server instance on the host.
It would also be possible to set up instances of SQL Server within each VM; but if you only needed one instance to be present, it would be best to have it installed somewhere else. This means that it doesn't even need to be anywhere on that system at all; it just needs to be somewhere on the network where the VMs can get to it.
On the whole, I'd recommend dedicating a whole physical server to running nothing but VMs whenever you can manage it, just so you can throw as much physical memory as possible at the problem.
Does Microsoft Virtual Server 2005 give direct access to network cards -- with no virtual router if needed -- and serial ports?
Yegulalp: Virtual Server emulates a multiport network adapter with up to four network connections per VM. It also emulates up to two serial ports that can be mapped to physical serial ports, local named pipes and files if needed.
