Our experts have answered many of your questions about VMware, Microsoft Virtual Server, virtualization management and Xen. We asked experts Anil Desai and Serdar Yegulalp to send us their most useful questions and answers about virtual machines for this FAQ. The questions cover backup, fixed versus dynamically-expanding virtual hard disks, how to choose the right virtualization approach, RAID and more.
If your question isn't answered after reading this FAQ, send your question in via our Ask the Experts section. Choose Anil Desai for virtualization management questions, or Serdar Yegulalp for Microsoft Virtual Server questions. We also have experts for VMware Server and Xen.
Is extra memory beneficial to virtual machines (VMs)?
In general, having more memory will allow you to run more virtual machines concurrently (with better overall performance). On many modern hardware systems, adding memory can be one of the most cost-effective ways to scale virtualization.
For example, VMs that are running on the 32-bit edition of Microsoft Virtual Server are limited to using up to 3.6GB of physical memory each. However, your Virtual Server host systems can certainly take advantage of more physical memory. The overall limit is based on the amount that is supported by the host operating system. So, for example, if your Windows Server 2003 Enterprise Edition computer has 12GB of physical memory, you can allocate this among your VMs.
How can I back up my virtual machines?
Two main approaches exist for backing up VMs. The first is to treat your VMs as if they were other physical nodes on your network. You can use tools such as Windows Backup to create backup files and then copy them to the host computer or to a network location. If you've invested in a third-party backup solution, you'll probably be able to use your existing software to install an agent within the virtual machine.
But what if you want to back up the entire VM from outside of the guest OS? You might be tempted to use solutions such as snapshots or open file agents to perform this task, but that can lead to backups that may be not be reliable. The quickest way to create a backup of a Virtual Server VM is to first place the VM in saved state, then copy all of the VM-related files, and then resume the VM. The entire process may take only a few seconds and is generally limited to the speed of the file copy operation. Furthermore, you can use the Virtual Server COM API to script the entire process so it run automatically and based on a schedule.
How can I deal with poor performance of virtual machines?
Typically, poor performance meanes that one or more subsystems (CPU, memory, disk, or network) is not running as fast as you'd like. And, compared to running on a physical server, response and throughput is significantly slower. Granted, there will always be some performance overhead related to virtualization. However, I recommend trying to isolate the actual bottlenecks using tools such as third-party benchmarking and performance utilities or a platform provider's tools, such as Windows System Monitor for Microsoft Virtual Server.
Using a utility, you'll likely find an area to focus on. For example, if you find that there's an excessive amount of paging within the VM, you might want to increase the physical memory allocation. There are methods for addressing issues such as disk-related contention, CPU competition and so on.
Rest assured: It's certainly possible to address many virtualization-related performance issues. It will, however, take some time and effort. (Note: These same techniques would apply to troubleshooting performance problems on a physical server, as well.)
Can I store virtual machines and virtual hard disks on a network share?
Yes. If you're supporting many different virtual machines, you might have a problem managing all of the virtual hard disk files you need for all of your installations of your virtualization platform product.
One way to help consolidate this is to store all of your virtual machines on a networked device, such as a standard Windows file share or on a Network-Attached Storage (NAS) device. If your virtual hard disks (VHDs) are configured to be read-only (e.g., if you're using differencing disks or undo disks), you can even have multiple virtual machines accessing the same VHD files at the same time.
Configuring this is pretty simple. For example, on Microsoft Virtual Server, just add the UNC path you need to the search path in the configuration of Virtual Server. Standard security requirements apply. The service account under which the Virtual Server service runs must have the necessary permissions.
How do you design a RAID array for placement of multiple virtual hard disks (VHDs)?
RAID file placement is one of those topics that's more art than science in some cases.
Start by categorizing the types of disk activity you have. For example, fixed-size and dynamically-expanding VHDs could have a lot of write activity (for example, if you're virtualizing a transaction-processing database), a lot of read activity (for example, in the case of a file server), or neither (in the case of Web server that caches most of its content). Next, look at the types of reads or writes: Are they primarily sequential or random? You can measure all of this using tools like the Windows Performance Monitor (see my article "Designing Virtual Hard Disk Storage" for more details.) Also, consider the activity patterns for undo disks and differencing disks.
Now, on to RAID: Your goal is to choose RAID configurations that allow you to minimize contention for disk access. If you have two large VHDs that generate a lot of random reads, for example, you might want to place them on separate spindles. RAID 0+1 or RAID-5 would be good candidates hear (since you won't have to worry much about parity calculation overhead). Some general tips are to separate base VHDs from their associated undo disks and differencing disks (since these are often accessed concurrently).
In a virtualized environment, how do I share a RAID-5 array from the host across the network?
Let's say you have a well-equipped server on which you want your new virtual machines (VMs) to run. You want to ensure that network shares that are created within the file/print server VM are available to other users throughout your network. In this case, all you need to do is attach the VM's virtual network interface to a virtual network that is connected to the host's network adapter. By default, a virtual network called "External Network" should have been created during installation.
If, on the other hand, you want to store virtual hard disks for your virtual machines on a remote storage device, that's also possible. I'm guessing that you might have an external storage array that's running RAID-5, and you'd rather have the VHDs stored on that remote server. If that is what you're asking, you can accomplish this through the use of Windows file shares, iSCSI, or SAN technology.
One final guess is that you want remote storage locations (such as a folder on a storage array) to be hosted by the file server VM. You want users to connect to the file server VM, but the actual storage requests should go to the RAID-5 array. In this case, you can rely upon iSCSI, SANs, or Microsoft's Distributed File System (DFS) technology.
How do I choose the right virtualization platform and approach?
Your challenge is finding the right virtualization tool for various jobs. Most of the current buzz is around server virtualization via either Microsoft's and VMware's platform. These solutions allow you to run multiple operating systems concurrently on the same hardware. Server virtualization is best for complex applications that require extensive configuration and system configuration.
Another approach to virtualization is that of allowing multiple applications to run concurrently on the same operating system. This is the general approach taken by SWSoft and other vendors. The idea here is that, for simpler applications, there's no need to run separate operating systems for each. The result is lower overhead, while still allow isolation for users.
The overall goal is to determine the best solution for your workload. Are you running a simple desktop application that must be installed multiple times? If so, application-level virtualization might be the most efficient way to go. On the other hand, if you're running complex multi-tier application suites, you might need to use dedicated virtual machines for the task. That's best-suited for server-level virtualization. I hope this helps you get a high-level idea of the options available!
What is the difference between a fixed-size and dynamically-expanding virtual hard disk (VHD)?
Both fixed-size and dynamically expanding virtual hard disks have a maximum size setting that determine how large the disk will appear to the guest OS. The difference is that fixed-size disks will take up the entire maximum size of the disk on the host file system while dynamically expanding disks will start small and grow as space is needed.
Dynamically expanding virtual hard disks provide the advantage of more efficiently using disk space on the host. So why would you want to use a fixed-size one? The main benefit is performance. Since there's no overhead related to expanding the physical VHD file, disk access can be significantly faster and disk fragmentation is often reduced. In addition, you don't have to worry about accidentally running out of physical disk space on the host (which can cause your guest operating system to crash). If these benefits aren't all that important to you, then stick with dynamically expanding VHDs. And, rest assured: You can always convert between these two types of virtual hard disks.
Is it possible to run virtual machine (VM) files on iSCSI and Storage Area Networks (SANs)?
Both iSCSI and SAN technology were designed to provide location-independent storage to computers. From the standpoint of the operating system, most applications and software can't tell the different between local storage and a mounted iSCSI or SAN volume. So, yes, you can definitely run your virtual machine files stored on an iSCSI-enabled device or within a SAN configuration.
That raises the question of performance. Since virtual machines can cause a lot of disk I/O, it's important that you test overall performance before relying on remote storage. In some cases, a well managed SAN or iSCSI architecture could improve performance. In other cases, problems such as latency or low bandwidth could cause your VMs to crash (remember that the guest operating system is expecting to access a local hard disk, and it's not willing to wait long for a disk I/O request to complete). Overall, using Virtual Server with remote storage can improve performance and manageability, but be sure to test your configuration.