AnilDesai.net

This article was first published on SearchServerVirtualization.TechTarget.com.

It’s rare these days to encounter computers or applications that don’t in some way rely on a network connection. General networking principals apply to virtual machines just as they apply to physical ones. But, since the host’s network adapters will be providing resources for all VMs, there are some special considerations, as well. In this article, I’ll present some ways in which you can design networks with virtualization performance in mind.

Note: For an introduction to working with Virtual Server’s networking options, see Configuring Virtual Networks in Virtual Server – Microsoft Virtual Server from the Ground Up.

Managing Host Network Adapters

When multiple VMs perform network-intensive operations, the host’s network adapter can become a bottleneck. In the simplest network configuration, a Virtual Server host computer will have only physical network port. While this system will allow you to share the network adapter with VMs, you can add some security and manageability by adding a second network port. Figure 1 shows an example. Since it’s a good idea to isolate network traffic (for security and performance reasons), you can choose to place all VMs on a separate Virtual LAN (VLAN) on your switch.

Figure 1: Using multiple host network adapters.

Since Virtual Server allows you to connect up to four virtual NICs per VM, you can add additional physical network connections, as needed.

Using the Virtual DHCP Server

Virtual Server’s built-in DHCP Server can be enabled for virtual networks and can help you create logically-separate networks on the same physical network segments. Through the use of differing IP address ranges, this technique can help segregate network traffic without requiring the configuration of VLANs or other devices on your switches. Figure 2 shows an example of a potential configuration.

Figure 2: Using DHCP to logically isolate network traffic.

Using NIC Teaming

The concept of NIC teaming is to allow multiple network ports to act as one logical unit. There are two main goals. The first is automatic fail-over. If one of the connections becomes unavailable (due to a port or switch failure), the other port can seamlessly take over the load. The other goal is performance: Having multiple ports working together in a group can increase effective bandwidth. Keep in mind that some configurations will depend on support from the network infrastructure-side (for example, port grouping options on switches).

Other network adapter optimizations include changing the default TCP packet size. If you’ll be routinely transferring large files (such as VHDs) between servers, using Jumbo Frames can greatly reduce overhead and increase performance.

Virtual Server and Firewalls

It usually goes without saying that firewalls and port-level filters provide an important layer of defense for Virtual Server hosts and VMs. Theoretically, if an unauthorized user gained access to your Virtual Server host, she could gain access to the VMs themselves. If you want to place a firewall between Virtual Server and potential users, you’ll need to keep in mind which ports you might need to open to make various services available (see Figure 3).

Figure 3: TCP Ports used by various Virtual Server-related services

Monitoring Network-Related Performance

When planning for virtualization network configurations, it can be useful to get statistics about traffic traversing the host and guest interfaces. Figure 4 provides an example of statistics that can be collecting using Windows System Monitor. When measured at the host level, you can get an aggregate summary of how much bandwidth is being used and if there’s an outbound queue. To drill-down on the source of the network information, each guest OS can be monitored. You can further filter the details per network adapter.

Figure 4: Network performance counters of the “Network Interface” object

Summary

There are many different ways in which you can configure networks to better support virtual machines. We looked at methods for segmenting traffic, increasing throughput, configuring firewalls, and monitoring network statistics. All of this can help optimize network performance in virtualized environments of any size.

This article was first published on SearchServerVirtualization.TechTarget.com.

Providing and managing storage resources in any IT environment can quickly grow out of control. When you’re using local storage, you often run into limitations based on the number of hard disks that can physically be attached to a single computer. Multiply these requirements by dozens or hundreds of servers, and it quickly becomes unmanageable. Fortunately, there’s a potential solution in centralized, network-based storage. In this article, we’ll look at how you can use network-based storage options to improve the performance and manageability of virtual machines running on Microsoft Virtual Server.

Effects of Network-Based Storage

Using network-based storage can have several effects on overall performance: some are good, some are (potentially) bad. Let’s start with the positive: Disk and network caching that is common on many storage solutions can help increase overall performance. When using centralized storage, even relatively small solutions might have multiple gigabytes of high-speed memory cache. Anytime you can avoid physical disk access is a win from a performance standpoint. Additionally, when using centralized storage, you can take advantage of advanced backup and recovery features such as snapshots and split-mirror features (the terminology and technology vary by vendor).

There are some down-sides to network-based storage. First and foremost is latency: performing round trips across a network can be time-consuming and long delays could lead to VM crashes. Also, the added burden on the network when multiple VMs are trying to use resources can require infrastructure upgrades. Overall, the benefits can outweigh the risks and difficulties (as long as you plan and test properly). With this in mind, let’s look at some technical approaches.

Sharing Virtual Hard Disks (VHDs)

The fact that VHDs are actually files comes with an unexpected benefit: Multiple VMs can access the same VHD files concurrently, as long as the VHD files are read-only. This is a great option if you’re already planning to use undo disks and/or differencing disks since the base or parent VHDs will be read-only, anyway. While you might increase contention and generate “hot spots” on the host file system, when sharing files with many VMs, these effects can be offset by caching. Only performance testing can provide the real numbers, but sharing meets your needs, you’ll have the added benefit of minimizing physical disk space usage.

Using Network-Attached Storage (NAS)

NAS devices provide access to files over a network connection. Standard Windows file shares are the most common example. While NAS devices can support several different protocols, in the Windows world, the CIFS standard is most common. Microsoft’s implementation (SMB) is the protocol that allows Windows users to access file shares. A simple approach involves configuring one or more virtual machines to access a virtual hard disk over the network using a UNC path instead of a local path. Figure 1 provides an example.

Figure 1: Accessing a VHD over the network

In order to implement this configuration, the Virtual Server service account must have access to the remote network location, and proper permissions must be set. Whenever a guest OS makes a disk I/O request, Virtual Server sends the request over the network to the VHD file located on the file share.

Using a Storage Area Network (SAN)

SAN technology is based on low-latency, high-performance Fibre Channel networks. The idea is to centralize storage while providing the highest levels of disk compatibility and performance. The major difference between SAN and NAS devices is that SANs use block-level I/OThis means that, to the host operating system, SAN-based storage is indistinguishable from local storage. You can perform operations such as formatting and defragmenting a SAN-attached volume. In contrast, with NAS-based access, you’re limited to file-level operations.

The major drawbacks related to SANs are cost (Fibre Channel host bus adapters and switch ports can be very expensive) and management. Generally, a pool of storage must be carved into smaller slices, each of which is dedicated to a server. This can often lead to wasted disk space (although many vendors have introduced methods for more dynamically managing allocation). Figure 2 shows a high-level logical view of a typical SAN implementation.

Figure 2: A basic Storage Area Network (SAN) environment

In order to improve management and reduce costs, configurations that combine SAN and NAS technologies are common in many environments. The Virtual Server computers can access VHD files using the NAS devices and the NAS devices, in turn, will connect to the SAN. This method can help reduce costs (by limiting the number of Fibre Channel ports and connections required) and simplify administration. Figure 3 provides an example of this type of configuration.

Figure 3: Combining NAS and SAN devices to store VHD files.

Using iSCSI

The iSCSI standard was designed to provide the storage characteristics of SCSI connections over an Ethernet network. iSCSI clients and servers (called initiators and targets, respectively) are readily available from many different vendors. As with SAN technology, iSCSI provides for block-level disk access. The major benefit of iSCSI is that it can work over an organization’s existing investment in copper-based Ethernet (which is dramatically cheaper than Fibre Channel solutions). Some benchmarks have shown that iSCSI can offer performance similar to Fibre Channel solutions. On the initiator side, iSCSI can be implemented as a software-based solution, or can take advantage of dedicated accelerator cards.

Comparing Network Storage Options

The bottom line for organizations that are trying to manage storage-hungry VMs is that there are several options available for centralizing storage. One major caveat is that you should verify support policies with vendors. Unsupported configurations may work, but you’ll be running without a safety net. And, I can’t overstate enough the importance of testing network-based storage configurations. Issues such as latency and protocol implementation nuances can lead to downtime and data loss. Overall, however, storing VHDs on network-based storage makes a lot of sense and can help reduce some major virtualization headaches.

This article was first published on SearchServerVirtualization.TechTarget.com.

IT staff and end-users tend to demand a lot from their hard disk subsystems. We throw thousands of files and move or copy gigabytes of data practically every day. So it probably comes as no surprise that, over time, this can take its toll on overall performance. Just like physical hard disks, virtual hard disk (VHD) files need to be maintained over time. In this article, I’ll present details related to maintaining VHD performance on Virtual Server host computers.

Note: For an introduction to working with Virtual Server’s disk architecture, see Understanding Virtual Hard Disk Options.

Monitoring Disk Performance

Since disk-related throughput and latency often affect overall VM performance, it’s important to monitor disk activity to see if you’re at or near the capacity of your exiting storage system. Figure 1 provides a list of useful System Monitor counters that provide statistics for determine whether disk performance is a bottleneck.

Figure 1: Disk-related performance counters

When monitoring disk activity at the host level, you’ll get an aggregate view of activity generated by the host and all VMs combined. These statistics are helpful for determining if a hardware upgrade or rearrangement of files is necessary. By viewing statistics at the level of each VM, you can determine which guest OS’s are generating the most disk activity. All of these details can help clue you in on how the disk subsystem is being used.

Defragmentation

Virtual hard disks are just as susceptible to fragmentation as are physical hard disks. The bad news is that you’ll need to worry about disk fragmentation at two levels: the host-level and within each guest OS. The frequency of running defragmenting operations will vary based on the amount and type of activity within the VMs.

As a general rule, you should use the same schedule that you would use for physical machines that are performing similar activities. So, on a busy file server, you might want to defragment frequently. And on a largely static-content web server, you might be able to go months without any performance degradation. The catch is that you need to coordinate defragmentation operations between VMs and the host: Running multiple defrag operations at the same time will significantly decrease performance and will put a much greater load on the physical disk subsystem. It’s a balancing act, but monitoring can help you determine the most appropriate schedule.

Compacting VHDs

Dynamically-expanding virtual hard disks can be compacted to reclaim space that is currently allocated on the host system, but that is not actually used within the guest. This situation can occur if you’ve deleted a lot of data from within the VM, or if files are often moved to and from the VM’s file system. Compacted VHDs are easier to move around (since they’re smaller), and can perform significantly better.

There are two main steps to getting optimal results. The first is to run the Virtual Disk Precompactor – a utility that is available as an ISO file that’s included with the installation of Virtual Server. Just attach the ISO (or access the utility over the network) and run the executable from within the VM. The pre-compactor will reallocate space to ensure that you get the most efficient compact operation.

With the prep work out of the way, you can compact the VHD using the Virtual Server Administration Web Site’s Inspect Virtual Disks function (see Figure 2). In order to compact a disk, it must not be attached to any running VMs. You’ll need roughly twice the total disk space of the size of the VHD, since Virtual Server actually creates a new VHD in the background. The process can generate a lot of disk I/O and can use significant amounts of CPU time, so you’ll want to perform the operation during periods of low activity. Other options are to script the process or to copy the VHDs to a non-production computer and compact them there.

Figure 2: Compacting a Virtual Hard Disk

Developing a VM Maintenance Plan

So far, we’ve looked at various ways in which you can improve performance. Now, let’s look at how you can bring this ideas together to maintain performance in a virtualized production environment. A regular virtual machine maintenance plan might include the following steps:

• Review virtual disk performance statistics and move VHD files, if necessary. (For more information VHD file placement, see the previous article in this series: “Designing Virtual Hard Disk Storage”)
• Compact all Dynamically-Expanding Virtual Hard Disks
• Defragment all Guest OS file systems
• Defragment the Host file system

The frequency of these tasks will vary based on usage patterns for VMs and the amount of downtime available (or, at least, the amount of time during which activity is low). It can be a lot of work, but it’s usually worth the effort. Third-party disk defragmentation tools can also assist with scheduling and centrally managing defragmentation operations.

A Stitch in Time…

The benefits of a flexible virtual hard disk architecture come at the cost of gradual performance decreases over time. In this article, we look at ways for monitoring and maintaining the performance of VHDs to ensure adequate VM performance. Next up in this series is the topic of using network-based storage for your VHDs.

This article was first published on SearchServerVirtualization.TechTarget.com.

By default, Virtual Server will treat all VMs with equal priority. In production environments, however, it’s common to have some VMs that are more important than others. Accordingly, you’ll want to let Virtual Server know which VMs should get preference. Virtual Server offers two main methods for managing CPU utilization per VM. To access the settings, click on “Resource Allocation” in the Virtual Server section of the Administration Web Site. Figure 1 provides a view of the default resource allocations for VMs.

Figure 1: Configuring CPU settings in the Virtual Server Administration Web Site.

The initial display might seem simple enough, but there’s a lot of potential power here. Let’s look at the two main ways in which you can configure CPU settings.

Weight-Based Resource Allocation

The simplest way to assign priorities to your VMs is to assign “weights” to them. When doling out CPU resources, Virtual Server will give preference to each VM based on its relative weight setting. The values can range from 1 (the lowest priority) to 10,000 (highest priority). By default, all VMs will have a relative weight setting of 100. Since the values are relative, you can setup your own conventions, such as using only values in the range of 1to 10 or 1 to 100. For example, if you want an important VM to have twice the priority of the others, you can set it to a weight of 200 (assuming that the other VMs are using the default weight of 100).

The preferences will kick in whenever CPU resources are limited. Weight-based resource allocation is the quickest and easiest way prioritize your workloads while ensuring that all CPU resources are still available for use.

Constraint-Based Resource Allocation

In some cases, you’ll want more granular control over how CPU resources are managed. That’s where constraint-based resource allocation comes in. This method is a bit more complicated (and you can make CPU resources unavailable if you don’t understand the settings). But, it can be very useful in production environments. You can specify two constraint types as percentages:

• Reserved Capacity: This setting tells Virtual Server to reserve a certain amount of CPU time for a VM, whether or not it is actually using it. Since it’s difficult to predict when an important VM will need resources, you can use this setting to ensure that one or more VMs will never be left waiting for CPU time. Just keep in mind that you can adversely impact other VMs running on the same machine, since the reserved capacity won’t be available to other VMs.

• Maximum Capacity: A potential problem when running multiple VMs is that one VM could monopolize CPU time and adversely affect all of the other VMs on the system. The maximum capacity setting specifics an upper limit to the amount of CPU time that a VM may use. Again, keep in mind that there’s a potential for wasted cycles: Even if there are no other VMs competing for resources, the amount of CPU power that can be accessed by the VM will be limited. This option is also helpful if you have other applications or services running on the host system, and you want to ensure that Virtual Server doesn’t dominate the machine.

By default, the reserved capacity is set to 0%, and the maximum capacity at 100% for all VMs. This effectively disables constraint-based resource allocation. Both settings can be defined as either a percentage of one CPU, or a percentage of all CPU resources on the system. The Administration Web Site automatically calculates the amount of resources left to allocate and shows the current CPU utilization per VM. Figure 2 shows an example of configured values.

Figure 2: Enabling Constraint-Based Resource Allocation

One other helpful feature: Resource allocation settings can be change dynamically while VMs are running. That can help troubleshoot problems with, for example, a VM that is hanging and trying to use all of the available CPU time.

Controlling Virtualization Mindshare

As you can see, there are several ways in which you can tune Virtual Server’s CPU resource referee. By letting Virtual Server know the relative importance of your VMs, you can help the virtualization layer make better decisions about how to ration resources. OK, that covers managing CPU resources: Next on our hit-list for performance optimization will be managing virtual hard disks.

This article was first published on SearchServerVirtualization.TechTarget.com.

The primary purpose of any virtualization solution is to act as a referee between virtual machines (which are always asking for access to hardware resources) and the underlying hardware itself (which can only respond to a limited number of requests at a time). In this article, I’ll cover ways in which you can moanitor CPU and memory resources.

Getting Host Hardware Information

When managing Virtual Server, a good first step is to get an overview of the host computer’s hardware configuration as seen by the Virtual Server service. To do this, just click on Server Properties – Physical Computer Properties (see Figure 1) in the Virtual Server Administration Web Site. Here, you’ll get a quick rundown of the key CPU and memory statistics.

Figure 1: Viewing the physical properties of a host computer.

Make a note of the number of physical and logical CPUs as well as the amount of available physical memory. These numbers will define the constraints under which you’ll be working.

Managing Memory Settings

Configuring memory settings for a virtual machine couldn’t be much easier: As long as the VM is powered off, you can change the memory setting in the properties of the VM. There are some rules to keep in mind: Most importantly, you cannot “overcommit” memory – that is, the sum of physical memory allocated to all VMs on a host server (whether or not they’re actually running) must be less than the total amount of physical memory available on the server.

If you’re going to be running other applications on the same server, keep in mind that you’ll need to reserve a certain amount of memory for the host OS, as well. Fortunately, Virtual Server can access all of the physical memory that is available on the host computer, including support for large memory on 32-bit systems and the increased address space of 64-bit host operating systems.

Physical CPU Considerations

When choosing CPUs for a host server machine, there are several things to keep in mind. First and foremost is the overall performance of the CPU architecture. Clock speed and the number of physical CPU cores are most important. Each virtual machine will run in its own thread, so having multiple CPU cores can greatly help improve performance. Additionally, Intel and AMD both offer virtualization-related extensions that can help improve virtualization performance (an upcoming Virtual Server update will add optimizations that take advantage of these specialized instructions).

Next, keep in mind issues related to heat and power consumption (both will end up hitting your overall budget). Multi-core CPUs offer significant performance advantages while minimizing additional power consumption. Keep in mind that, regardless of the number of physical and virtual CPUs present on the host, each VM will be limited to seeing only a single virtual CPU. Rest assured that Virtual Server will use all of the available host CPUs, as needed.

Monitoring CPU and Memory Performance

Before you can start tweaking CPU and memory settings, you should get an idea of how these resources are being used. Figure 2 provides some useful Windows Performance Monitor counters, and how they can clue you in on what’s going on. It can be valuable to measure these values both at the host-level (for an overview of aggregate hardware utilization) and at the VM-level (to hone in on details related to individual VMs’ resource usage).

Figure 2: Windows Performance Monitor counters for measuring CPU and memory statistics.

Summary

In this article, we looked at the ways in which Virtual Server automatically manages access to CPU and memory resources, and how you can monitor actual usage. We’ll build on this information in the next article when we look at manually managing CPU resource allocations. Stay tuned!

This article was first published on SearchServerVirtualization.TechTarget.com.

Issues related to performance rank high on the list of technical concerns related to virtualization. Organizations are often ready to jump toward the use of virtual machines, as long as they can be sure that their applications will continue to perform well. While it’s a fact that virtualization overhead is inevitable, it’s more important to understand how to address bottlenecks and increase performance.

In some ways, this sounds like the not-so-good old days, where systems administrators would go to great lengths to squeeze the maximum performance out of 64MB of RAM on a mid-range server. While hardware constraints are nowhere near as tight as they used to be, it’s still up to IT staff to get the highest performance out of their systems. Fortunately, there are many ways to reach this goal.

This series of articles will focus on strategies for optimizing the performance of virtual machines running on Microsoft Virtual Server 2005 R2. While most of the general tips apply to other virtualization platforms (such as VMware and Xen), I’ll focus on Microsoft’s platform when illustrating specifics. I’ll cover methods to optimize CPU, memory, disk, and network performance. The goal is to help you manage and optimize performance based on Virtual Server’s architecture and your business and technical needs.

Note: The articles in this series assume that you’re already familiar with the Virtual Server platform and have experience working with virtual hard disks, virtual networks, and other settings. If you’re new to virtualization, be sure to check out my previous series of articles: “Virtual Server: From the Ground Up”.

This article was first published on SearchServerVirtualization.TechTarget.com.

People often equate the ability to choose with freedom. That’s usually a good thing, but Microsoft has two virtualization offerings that are both great products at a great price (free). Your options are Virtual Server 2005 and Virtual PC. So which one is better? Well, it depends on what you’re trying to do. In this article, I’ll talk about the differences between these two products, and about how you can switch between them.

A Tale of Two Platforms

If you look at Microsoft’s two virtualization options from a marketing and technical standpoint, there’s one conclusion that seems consistent: Virtual PC has been designed to make virtual machines accessible to desktop users, whereas Virtual Server provides powerful Enterprise-class features. If you’re squarely in one camp or the other, then the decision might be simple. The two products do have a lot in common, but there are some important differences. Let’s take a look at the details.

Virtual PC: Easy Does It

Virtual PC has been designed to be as simple to install and use as possible. That makes it a great solution for people who want to run one or two VMs on their desktops with minimal setup hassles. Perhaps the most noticeable feature is that Virtual PC comes with a standard Windows application for administration. The user interface is familiar and user-friendly (see Figure 1), and most users should be able to get up and running in a matter of minutes (assuming they understand basic virtualization concepts).

Figure 1: Configuring VM hardware settings in Virtual PC.

There are more useful features in the area of administration. A very handy feature is that virtual machine windows can be resized while they’re running (just like you might resize a Word document or e-mail message). As long as the guest OS is supported by the Virtual PC platform, its desktop resolution will scale automatically.

A common task when working with VMs is to transfer files between the host computer and the VM. While you could certainly accomplish this through the use of networking, Virtual PC allows you to simply drag and drop files between the host and guest OS through the use of Shared Folders. Also in the area of networking is the ability to configure Network Address Translation (NAT) to easily share the host’s network connection without worrying about network addresses. Finally, Virtual PC includes an emulated virtual sound card. It may not rock your world, but it can be helpful for testing some applications.

Virtual Server: Power to the [IT] People

Virtual Server has been designed to host many virtual machines, efficiently and reliably. It runs as a service on Windows XP or Windows Server 2003 computers. Due to its multi-threaded architecture, it can simultaneously run many VMs (assuming you have enough CPU, disk, and memory resources). Virtual Server also supports both 32-bit and 64-bit host operating systems. The most noticeable difference between the two products is that Virtual Server is managed using an Administration Web Site (see Figure 2). While this can be more accessible (all someone needs is a browser in order to manage it), the interface isn’t nearly as user-friendly as a Windows application.

Figure 2: Using the Virtual Server Administration Web Site.

Other than performance, Virtual Server provides numerous additional benefits. One of my favorite features is scripting and automation support through the use of a Component Object Model (COM) interface. The API is well-documented and you can use VBScript, Visual Basic.NET or C# to manage your VMs. As you might expect from any Enterprise product, Virtual Server offers advanced networking and security features. It also provides support for SCSI-based hard disks (allowing terabytes of total storage), iSCSI network-based storage, and clustering (both at the host and guest levels). You can also manage Virtual Server using Microsoft Operations Manager (MOM), or third-party tools.

Feature Comparison

Nothing sums up features and differences like a good table. Figure 3 provides just that.

Figure 3: A summary of features of Virtual PC and Virtual Server

The Best of Both Worlds?

If you still can’t decide which platform is best, here’s a reassuring fact: For the most part, VMs are portable between the two platforms. You can create a VM in Virtual PC and then later run it within Virtual Server (or vice versa). This can be very handy in development, testing, support, and other related situations. There are a few things to keep in mind, however. First, the saved state file formats are not compatible between the two platforms. So, you’ll need to completely shut down a VM before you move it between platforms. Virtual Server does not support virtual sound cards (most Guest OS’s will automatically detect this), and Virtual PC does not support virtual SCSI hard disk controllers. The latter is mainly an issue for boot volumes, since you can always take a virtual hard disk file and move it between SCSI and IDE attachments.

Overall, if you don’t mind a bit of a learning curve and you want to host multiple VMs as efficiently as possible, Virtual Server is probably the best bet. If, on the other hand, you just want to run one or two VMs as quickly as possible, then you should probably start with Virtual Server. You really can’t go wrong with either one, since you can change your decision pretty easily and the cost of admission is free. Good luck!

This article was first published on SearchServerVirtualization.TechTarget.com.

While virtual machines working in isolation can be useful for some purposes, modern day applications and operating systems often rely on network connectivity to accomplish their tasks. The challenge is in finding the right balance between ease of communications and security. In this article, I’ll cover details about virtual networking options in Microsoft Virtual Server 2005. Read on, so you’ll be able to ensure that no VM is an island (unless, of course, you want it to be).

Virtual Server’s Networking Architecture

Let’s start by taking a look at the architecture of how Virtual Server handles network access. Figure 1 provides a high-level view. Starting from the bottom, you have your physical network – the actual cables, switches, routers, and other devices to which the host computer is connected. Above that is the host’s physical network interface card (NIC) and its associated driver. That’s the standard stuff. Virtual Server adds a layer called the “Virtual Machine Network Services Driver”. It’s the responsibility of this layer to allow virtual NICs (which are configured within the VM) the ability to access the physical network.

Figure 1: An overview of Virtual Server’s network architecture

In the simplest configuration, you’ll likely have only a single physical NIC and a single virtual NIC. However, Virtual Server supports as many host NICs as you can install on the host OS, and up to four virtual NICs within each VM.

Understanding Virtual Networks

Virtual Networks are created within Virtual Server to simplify the administration of networking options. One option is not to attach the VM’s NIC to any virtual network (or to not use a virtual NIC at all). In that case, the VM will not be able to communicate with other physical or virtual machines. If you do want to enable communications, there are two main types of virtual networks options.

Guest-Only Networks

A good way to minimize network security risks is to create a virtual network that restricts virtual machines to talking only to each other. Figure 2 shows an example. You can create many different Guest-Only networks, simply by choosing not to bind them to any of the host’s physical network adapters.

Figure 2: A logical overview of Guest-Only virtual networks.

External Networks

When you choose to connect a host network adapter to a virtual network, all VMs that are connected to that network will act as if they were physically connected to the host’s LAN (see Figure 3). In fact, other computers on the same network will have a hard time distinguishing that these machines are VMs. While this offers the best connectivity, it comes at the risk of security (you must ensure that your VMs are properly patched and secured), and manageability (VMs must use compatible network addresses).

Figure 3: A logical overview of Guest-Only virtual networks.

Creating Virtual Networks

The good news is that, once you understand Virtual Server’s networking architecture, creating and managing virtual networks is pretty simple. First, let’s look at how you can place limits on which physical network connections can be used.

Enabling Host Network Adapters

It’s not uncommon for server-side computers to have multiple physical network adapters. This is often done to segment traffic (for example, in the case of a public web server), or for performance (for example, creating a separate network connection for performing backups). In these cases, it’s likely that you’ll want to tell Virtual Server that one or more network interfaces is “off limits” for VMs. You can do this by editing the properties of the appropriate network connection and unbinding the Virtual Machine Network Services item (see Figure 3). The rules are simple: If the box is checked, then virtual networks will be able to use the physical adapter. If not, the network connection will not be available.

Figure 4: Configuring the Virtual Machine Network Services item in the properties of a host network adapter.

Managing Virtual Networks

OK, now that we have all the pre-requisites out of the way, it’s time to fire up the Virtual Server Administration Web Site. By clicking on the items in the “Virtual Networks” Section, you can create and configure virtual networks. Figure 5 shows the screen you’ll see when creating a new virtual network. The name of the virtual network can be anything descriptive. Next, you can choose whether you want to bind the network to one of the host’s physical network adapters, or if you want to create a guest-only network. Finally, this page will automatically list all virtual network adapters that are not currently connected to a virtual network and will allow you to connect them directly. Click OK, and your virtual network should be ready for use.

Figure 5: Create a new virtual network.

Configuring VM Network Adapters

You can connect virtual network adapters to virtual networks by editing the configuration of an existing VM. Figure 6 shows the configuration of a VM that has multiple virtual NICs. Note that you can specify a static MAC address, or you can have Virtual Server automatically create one that will avoid conflicts. The best news is that you can connect and disconnect virtual network attachments even while the VM is running (just be sure that your OS and applications are OK with this).

Figure 6: Modifying virtual network adapter properties for a VM

More Virtual Server Networking Features

In this article, I covered the basics of getting up and running with Virtual Server’s networking options. But wait, there’s more! Virtual Server includes a built-in DHCP server that can be used for each of your virtual networks. As with physical network environments, this can help to greatly simplify the management of network addresses (especially if you often copy or move VMs). Of course, if your VMs are participating on the host network, you can use DHCP and other network services that might already be available.

Both Windows XP SP2 and the Windows Server 2003 platform offer built-in firewall functionality, and an Internet Connection Sharing (ICS) feature. Both of these are available for you to use with your VMs through an interesting application of the Microsoft Loopback Adapter (see Virtual Server Books Online for more details).

Overall, Virtual Server’s networking architecture is flexible and easy-to-manage, once you know how it all works. Keep this information in mind when you’re trying to determine the best balance between communications and security for your VMs.

This article was first published on SearchServerVirtualization.TechTarget.com.

If you’ve been following the article series so far, you’ve already setup Microsoft Virtual Server, configured some basic server settings, and have created a new VM. What’s missing in this picture? Well, so far, the VM doesn’t do much – you can start it, but all you’ll get is a black screen stating that no operating system can be found. That makes sense – so far, you have the equivalent of a physical computer with a blank hard drive. The next logical step is to install a guest operating system. You’re in luck, as that’s the topic of this article!

Guest OS Installation Overview

The process of installing a guest operating system is similar to that of installing an operating system on a new physical machine. You need to start with some way of getting the OS installer (and all related files) onto the computer. In the old days, you’d likely use floppy disks. Now, CDs, DVDs, and network-based installs are more common. Literally hundreds of operating systems have been successfully run with Virtual Server (though only a small subset of them are officially supported by Microsoft). In general, as long as your guest OS supports the hardware configuration shown in Figure 1, you should be able to run it within a Virtual Server VM.

Figure 1: The virtual hardware configuration for a Virtual Server VM.

The main concept to keep in mind is that, in almost every way, the guest OS will function like a physical one. It has a BIOS, it performs a POST operation, and it enumerates removable drives and fixed hard disks during the boot process. You can even go into the BIOS to make changes (though the default options will probably work best). OK, with that out of the way, let’s look at installation options.

Guest OS Installation Options

On a physical machine, you’d most likely start the installation of a new OS by inserting a CD or DVD into the system. Since there are no physical drives for a virtual machine, you’ll need to attach your VM’s virtual DVD-ROM drive (which also supports CD-ROMs) to the appropriate media. To manage these attachments, simply choose to edit the configuration of your virtual machine using the Virtual Server Administration Web Site. Let’s look at the three most common methods.

Installation Using Physical Media

If you have a physical CD-ROM or DVD-ROM from which you can install your guest OS, the simplest approach is to “capture” host computer’s physical DVD-ROM drive to your VM’s virtual DVD-ROM drive. To do this, go to the configuration of your virtual machine and then click on the “CD/DVD” link. As shown in Figure 2, you’ll have several options. Just select “Physical CD/DVD drive” and choose the appropriate drive letter from the host.

Figure 2: Capturing a physical CD/DVD drive.

The next time the VM is booted, it should automatically detect the media as if it were mounted in a virtual DVD-ROM device. Assuming that the media is bootable, you’ll be off and running with the Guest OS installation process. This is a pretty simple process, but there’s one catch: Using physical media can be a very slow method of installing an OS. Also, only a single VM can capture a physical host drive at a time (a problem if you’re planning to run multiple installations in parallel). Fortunately, there’s another option.

Installation Using ISO Files

The ISO standard specifies a method by which disc-based media formats (like DVDs and CDs) can be represented in a file. You can create an ISO file using various third-party utilities, and it has become very common for OS distributions to be available for download in ISO formats. If you have an ISO file, you can easily make it available for use by a VM, as shown in Figure 3.

Figure 3: Attaching to an ISO file to a VM’s Virtual CD/DVD drive.

Installing from an ISO file is usually significantly faster than using physical media, and multiple VMs can attach to the same ISO file at the same time.

Network-Based Installations

The Pre-boot eXecution Environment (PXE) standard allows for computers to be booted over a network. There are several requirements for this to work properly. First, the virtual network card must support PXE booting. Virtual Server has you covered here (as long as you’re using Virtual Server 2005 R2 or later). The other is that a collection of server-side technologies need to be available. Various vendors (including Microsoft) have PXE-based installation methods for their operating systems.

Using the VMRC

Once you’ve captured the appropriate media for installation, all you need to do is start the VM and use the VMRC to connect to it from within the Virtual Server Administration Web Site. Both operations can be performed by clicking on the thumbnail of the VM in the “Master Status” page.

Completing the OS Installation

Obviously, the exact steps for performing an OS installation will vary based on the specific OS. Again, keep in mind that the process should be similar (if not identical) to that of installing on a physical machine.

The first step that you’ll want to perform after the OS installation is complete is to install the Virtual Machine Additions. This package includes drivers and related software that will greatly improve VM performance and usability. The easiest way to do this is to click the “Install VM Additions” link when using the VMRC. Behind the scenes, Virtual Server will automatically mount the appropriate ISO file and (if your OS supports it), will automatically start the installation process. Once you reboot the VM, you should be all set to do what you will with your new VM.

Virtualization Checkpoint

In the first three articles in this series, we’ve gone through the process of setting up a new VM and getting it ready for use with a guest OS of your choice. In future articles, I’ll cover details related to other configuration options such as configuring virtual networks. Stay tuned!