Converting Physical Servers to Virtual Machines

In almost any virtualization project, you will run into the need of converting physical machines to virtual machines. Both VMWare and Microsoft provide solutions for that. Here is the link that gives the details of the vmware converter. And here is the link for the Microsoft Virtual Server Migration Toolkit and another one that details VMM (Virtual Machine Manager) over here.

We have used the vmware one quite a few times and it is pretty easy to use and very robust as well. It does not require any downtime either. Haven’t had any experience with the MSFT toolkit so will post on it once we play with it in our labs.

Virtualization Wars

We have covered virtualization before at our blog but mostly VMWare and a couple of posts on Virtual Server as well. With Windows Server 2008’s Hyper-V, it looks like it will challenge the market even more for ESX Server 3.5. With hardware changes coming in way faster than the software changes, the servers age out faster due to hardware issues rather than the OS. With virtualization, a physical server can easily be migrated into a virtual environment with the same applications and then moved on to a new physical hardware. We have clients who are using virtualization now even in their production environments let alone the development and QA environments.

If you are not already using virtualization in your environments, now would be the time to start getting serious about it. With Hyper-V, the technology moves the virtualization layer directly against the hardware. Hyper-V allows virtualization of both 32 bit as well as 64 bit architectures. MSFT has extended their virtualization platform offering by providing Microsoft App. virtualization (this was known as SoftGrid before) and desktop virtualization. not only that, one can use the System Center Virtual Machine Manager to do centralized management of a virtual set up.

Not only are these choices cost effective by providing us with consolidation and DR/HA (Disaster Recovery and High Availability) choices, it also eases up maintenance work for System Engineers as well as DBAs. An added benefit of consolidation is reduced electricity costs

Both ESX Server 3.5 and Hyper-V are based on hypervisor based architectures which are better than the previous hosted virtualization technologies. In the case of the hosted virtualization products, one had to run the virtualization software on top of the OS of the machine and that adds a lot of overhead and not only that, it has a longer code execution path for the VMs. Hypervisor based architectures run the hypervisor directly on the hardware which means that there is no OS between the hypervisor and the system hardware. Even though both ESX Server 3.5 and Hyper-V as both based on hypervisor base architectures, there are a good bit of differences between them. We are currently doing some benchmarks with ESX Server 3.5 as well as Hyper-V and will post the results of the tests at our blog as and when they become available and we consolidate them. Till then, you can read more on these over here:

ESX Server 3.5

Hyper-V and the FAQs

Some more Virtual Server Resources

Here are some good virtual server resources from MSFT:

Virtual Server Operations Guide:

http://technet2.microsoft.com/windowsserver/en/library/ce2499f6-f592-4eec-946f-56ff352e3e291033.mspx?mfr=true

Virtual Server Technical Reference:

http://technet2.microsoft.com/windowsserver/en/library/c3663e92-0992-4f6f-9870-513040f5f2be1033.mspx?mfr=true

Virtual Server Community:

http://www.microsoft.com/windowsserversystem/virtualserver/community.aspx

Virtualization in the database world

Virtualization is rapidly changing how we consolidate our servers for testing and deployment, for training and for disaster recovery. We have VMWare machines running in our office with clustered SQL Server and clustered Oracle environments. It is a great way to test out new software and play around with the new functionality as well as test out your disaster recovery scenarios without investing millions on hardware. It is also a good way to consolidate your servers and use them for development and QA purposes.

Both VMWare’s VMWare Server and MSFT’s Virtual Server 2005 R2 support 64-bit architecture on the host which means more memory utilization on the host seerver (up-to 1 Tera-byte) which translates into the capability of running many more active VMs. When you are getting ready to consolidate your servers into the VMs, you should remember to allocate 32MB per VM to account for the VM overhead. So, if you have an Oracle database for which you have allocated say 2GB of memory (overall), when you move to the VM, you would need (2 * 1024) + 32 MB for the VM. And you need to ensure that there is enough RAM left for the host as well. Another thing to consider is the usage of a SAN for the host server. You should create the VM’s virtual hard drive on a drive that is different than the host’s operating system - this is to reduce any possibility of a drive and spindle contention. Best thing is to use a SAN to help improve the I/O for the VMs. One more things to remember is that the virtual hard drives can be configured with their default settings to dynamically expand as needed. However, this is not good for performance. We would recommend to pre-allocate a fixed amount in order to avoid the performance hit of the expansion.

Here is the link to the whitepapers from VMWare on this topic:

http://www.vmware.com/solutions/whitepapers.html

Using vhdmount to access the virtual disk files

In the release of Virtual Server 2005 R1 SP1, Microsoft included a tool called VHDMount which allows one to connect to a vhd disk on your host operating system as if it were a separate physical disk. It makes sharing of the files a lot more simpler. Our partner company, Cerkitek has a good blog post on the usage of this tool. You can access that post here:

http://cerkitek.wordpress.com/2007/08/12/accessing-virtual-disk-files-with-vhdmount/