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

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

Configuring RedHat Linux AS 3.0 virtual machine using VMWare

Here are the steps to configure a RedHat AS 3.0 virtual machine using VMWare:

1)    Start the Host Configuration in the VMWARE console.

2)    Right click on the Virtual Machine you wish to configure and choose “Virtual Machine Settings”.

3)    In the screen that pops up, choose the NIC (usually NIC1) you wish to configure.

4)    On the right hand side of the screen change the “Adapter Type” to vmxnet.

5)    Once this is done you will need to start the Virtual Machine.

6)    Once the Virtual Machine is booted, log in as root.

7)    Once logged in you will need to open a terminal. (Command prompt).

8)    Type the following using the same case:
unset DISPLAY

9)    Execute vmware-config-tools.pl  (when prompted, choose “no” when asked if you wish to change your guest x resolution).

10)    Execute the following command:
/etc/init.d/network start

11)    Click on the start button in the bottom left (a red hat).  Choose “System Settings” then choose Network.

12)    A screen will pop up.  Delete any failed/non-working devices.

13)    Click New, then Ethernet Connection, then Forward.

14)    Choose “vmxnet” and click Forward, then Forward again, then Apply.

15)    Save the Changes when prompted.

VMWare Symposia 2007

VMWare holds a number of national and regional conferences every year, and best of all the majority of these conferences are free of charge. The VMWare Symposia is one such conference, and is an outstanding way for virtualization novices to become more familiar with virtualization technologies, and for experienced VMWare fans to interact with their peers. Even the most senior VMWare administrators can learn something new - it has been the author’s experience that not a single conference or meeting has gone by without gaining some new knowledge.

Symposia 2007 is being held in a number of major cities in the United State and Canada, incuding Atlanta, Dallas, Chicago, and Toronto. It is a day-long deep dive into some the latest VMWare products and technologies. Highlights include presentations by virtualization experts, customers, and industry analysts, live demos of virtualization solutions, case studies, and free software handouts at the end of the day.

To learn more about and register for Symposia 2007 visit VMWare’s Symposia website at:

http://info.vmware.com/content/Sym?&Src=web_homepage

More on virtualization

Second beta version for VMWare for Macs software (code named fusion) is now available as a free download and the finished product is expected to be released sometime in this summer. The first beta version of the software was introduced last year in April. If you recall, rival parallels had mentioned about an update to it’s desktop for Macs Software this week.

Both in essence use virtualization to run Windows on an Apple computer and allow the user to switch between Mac and Windows without a need for a reboot.

VMWare Releases Workstation 6.0 Beta

VMWare recently released the 6.0 version of its Workstation virtualization solution. VMWare Workstation is intended as a single-user product, and is essentially an application installed on top of a Windows operating system.

New in Workstation 6.0

The big news with this latest release is that Workstation 6.0 supports Windows Vista as the host operating system. Previous versions of Workstation provided support for Vista virtual machines, but had to run on either a Windows 2000/2003/XP host operating system. Other features include support for both 32-bit and 64-bit operating systems, dual-monitor capability, and support for USB 2.0 devices.

In addition to the above-mentioned features, Workstation 6.0 offers two other new features that will be of particular interest to developers:

Virtual Debugging- Workstation 6.0 now comes with virtual debugging capabilities, which integrates with development tools such as Visual Studio and Eclipse so that developers can deploy, test, and debug programs directly within the virtual machine.

VM Record/Play - This is an experimental feature offered in the 6.0 Beta release that allows users to record the activity and configuration changes within a virtual machine over a given period of time, which then allows you to accurately duplicate the operations and configuration of the virtual machine during the time of the recording. This will be an incredibly handy tool to help pinpoint when certain changes (good or bad) were made to the virtual machine.

VMWare Workstation 6.0 is available for download at: http://www.vmware.com/products/beta/ws/ , also be sure to review the release notes and documentation of this interesting new release.

Exporting and Importing Virtual Machines Using ‘vmkfstools’

Importing and exporting virtual machine from a VMWare ESX Server host involves converting that virtual machine’s .vmdk file(s) from one format to another. Even though other versions of VMWare (GSX Server, Workstation, etc) also use virtual machine files, the format is slightly different. Since GSX and Workstation run on top of a Windows operating system, they are not able to use the VMFS file system native to VMWare. Only ESX Server, which is basically its own operating system, has the ability to use VMFS.

VMKFSTOOLS

Often times administrators find themselves in a situation where they must either move a virtual machine created in GSX Server or Workstation to an ESX host server, or the other way around. One way to accomplish this is to use the ‘vmkfstools’ command, which is included with all versions of VMWare ESX Server. Vmkfstools is a powerful command that lets you manipulate virtual machine files.

Exporting Virtual Disks from ESX Server

In order to run a virtual machine created in ESX Server on another VMWare platform, the .vmdk files need to be converted into a format that can be read by the Windows FAT or NTFS file systems (remember that VMWare GSX Server and Workstation run on Windows).

The vmkfstools command and switches required to acheive this conversion are as follows:

In ESX Server 2.5 and earlier:

vmkfstools -e <folder>/<filename>.vmdk <vmhba number>:<filename>.dsk

<folder> is the name of the folder that you are exporting

<filename> is the name of the actual virtual machine file(s) you are exporting

<vmhba number> is the name of the VMFS partition the above files and folders are located in.

An example of a complete command would be:

vmkfstools -e /mnt/vmfolder/vmserver1.vmdk vmhba0:0:8:vmserver1.dsk

Once the conversion has been completed you can copy the files to the destination VMWare host server and add the files as a new virtual machine.

Note: ESX Server 2.5 may use a .vmdk file extension instead of the .dsk extension shown in the example. In that case the last part of the example would be ‘vmhba0:0:8:vmserver1.dsk’

In ESX Server 3.0:

vmkfstools -i /vmfolder/vmserver1.vmdk -d 2gbsparse /dest/folder/vmserver1.vmdk

Note: the destination path /dest/folder/vmserver1.vmdk shold not contain any existing files with the name ‘vmserver1.vmdk’. If it does the file will be overwritten.

Importing Virtual Disks from GSX Server and Workstation to ESX Server

Before an ESX Server can run a virtual machine created on a different version of VMWare, the virtual disks must first be converted to a format that can be read by the VMFS file system. This is done by running the following vmkfstools command:

vmkfstools -i <folder>/<filename>.vmdk <vmhba number>:<filename>.dsk

<folder> is the name of the folder from which you are importing from

<filename> is the name of the virtual machine file(s) to be imported

<vmhba number> is the name of the VMFS partition you are importing to

An example of a complete command would be:

vmkfstools -i /mnt/vmfolder/vmserver1.vmdk vmhba0:0:8:vmserver1.dsk

As you may have noticed, the only difference between the export and import commands are the ‘-e’ and ‘-i’ switches.

Additional information regarding the vmkfstools command can be found in the ESX Server documentation. However, additional entries about vmkfstools will also be written in the near future
 

VMWare ESX Server Disk Structure

Disk structure and technologies used in a virtualized environment are quite different than in the physical computing world. Each virtualization vendor has their own methods for implementing a virtual disk environment. This blog entry focuses exclusively on the disk structure of VMWare’s enterprise virtualization solution - ESX Server.

Virtual Machine File System

ESX server uses VMWare’s virtual machine file system (VMFS) for the storage of virtual machines. VMFS is a high-performance file system that runs on physical SCSI disks and partitions, including storage attached network (SAN) environments. It’s designed purpose is to store large files such as virtual disk images, as well as the memory images of suspended virtual machines.

Virtual Machine Disks

Virtual machines are stored on an ESX Server’s VMFS partitions. However, each virtual machine also has its own set of files. These files are in a special format and use a .vmdk file extension. A virtual machine can have one or many .vmdk files associated with it, depending on the size and configuration of that virtual machine. The .vmdk file can contain all of the virtual machine’s information, or if the virtual it can serve as a symbolic link from a VMFS to a raw logical unit number (LUN) when raw device mappings (RDM) are used from a SAN.

Redo Log Files

The most straightforward scenario is where the .vmdk file contains the virtual machine’s information. All changes to the virtual machine’s virtual disk are immediately written to the .vmdk file. However, there is a snapshot feature that administrators can use to save the current state of a virtual machine. This snapshot generates a redo log file, and all changes to the virtual machine from that point on are written to the log file, which has a .vmdk.REDO extension. The .vmdk file itself remains static. In this case, the term ‘log’ file is somewhat of a misnomer, as the REDO file is more than just a log, but a complete record of the virtual machine’s state.

 Accessing and Managing Virtual Disks

VMWare virtual disks are accessible via the following methods:

• The ESX Server Service Console
• VMWare Virtual Center
• The VMWare SDK

From the service console, files can be viewed and manipulated using ordinary command line commands. The directory where the files are located is always /vmfs.

Additionally, administrators can use the vmkfstools to import and export .vmdk files from different VMWare host servers. The command can also be used to convert .vmdk files from one version of VMWare Server to another.

Hopefully this high-level overview of the basice VMWare virtual server file structure will provide you with more insight into the overall virtualization infrastructure. Future blog entries will dig deeper into each component of a VMWare implementation, including Service Console usage and features as well as more details on how to use the ‘vmkfstools’ command.

How VMWare ESX Server Allocates CPU Resources to Virtual Machines

As previously mentioned, VMWare’s virtualization technology allocates physical hardware resources (processor, CPU, etc) to virtual guests running on a VMWare host server. The most common version of VMWare in production today is their ESX Server platform. It not only allocates the resources, but dynamically controls the amount of resources each virtual guest receives based upon the on-demand need of each guest system.

Virtual Machine Ready Time

There are a number of challenges that accompany a virtualized server infrastructure. To achieve optimum performance in a consolidated virtual environment, one must consider what is known as ‘ready time’, which is defined as the time a virtual machine must wait in a ready-to-run state before it can be scheduled to have resources allocated to it on one or more of the host server’s physical CPUs.

Access to the physical CPU is handled by the ESX Server scheduler. As the number of virtual machines increase, and/or the CPU utilization ramps up, the scheduler is more likely to force a virtual machine to wait for CPU resources. Even virtual machines that are basically running in an idle state need small amounts of CPU time to conduct various maintenance tasks.

Resource scheduling in a virtual environment is more complex than it is in the physical world. This is because there are two layers of scheduling rather than just one. In the physical world, the operating system directly allocates CPU resources to applications. In a virtual environment, the ESX server scheduler allocates a ‘chunk’ of CPU time to the virtual operating systems, and those operating systems allocate what are now virtual CPU resources to the applications running on that virtual machine.

There are a number of factors that affect a virtual machine’s ready time, including:

• Overall CPU utilization - obviously, if the CPUs of the host server are already heavily taxed, ready times will be high
• Number of virtual machines running on the host server
• Load correlation - If one process requiring CPU time ends and triggers only one new process, ready times will remain low. However, if that original process spawns a number of simultaneous tasks, the likelihood that you will see higher ready times will increase.
• Number of virtual CPUs configured for a virtual machine - If a virtual machine is configured to use two CPUs rather than just one, both physical CPUs must be available at the same time if a multithreaded task needs to be scheduled.

The multiprocessor aspect adds yet an additional factor to the scheduling scenario - virtual machines that have been scheduled to run on a particular CPU will be given priority to run on that CPU again the next time CPU time is required, which could basically be considered “cutting in line” so to speak, ahead of other requests already in the queue.