Networking

Making a P2V conversion: Tricks for systems with large storage

Converting a system with a large amount of locally attached storage can be a challenging task given the time required to perform the conversion. Here area a few tricks I’ve found that can help ease the pain on these types of conversion tasks.

• Private network: Making a private network between the physical host and the virtual host can provide two benefits. The main benefit is that conversion traffic will be isolated from the rest of the network traffic; the other advantage is that there is no risk of a user or process connecting to any resources and making changes during the conversion. The downside is that there may be special host-side configuration for a temporary network presence to allow the special network.
• Direct LUN mappings: For virtualization platforms that allow guest VMs to access a LUN directly, it can be much easier than performing a lengthy conversion of large data volumes that are already on a storage area network (SAN) and mapped to a physical system. Here is a blog post with a little more detail on that topic.
• Housekeeping: If there is junk on the physical system, does it need to be converted to the virtual environment, which may have more expensive storage? Clean up the candidate’s file system, and perform obvious tasks like emptying the Windows Recycle Bin. This allows for a more accurate re-sizing of the drives during the conversion.
• Agent backup and restore: For standard file volumes, such as a file server, it may make more sense to only convert the system drive and perform an agent-based restore to the virtual machine for the additional volumes. This does not necessarily save time from the entire conversion, but saves time within a tool like VMware Converter.
• Get a good time estimate: If you have to go at the large storage system as-is, make sure you have a baseline of about how many GB can be converted per hour. A good way to test this is to convert a good candidate system of about 100 GB and use that as a multiplier for your environment. There are a lot of factors, such as network speed and traffic, virtualization platform, storage systems (on both ends), and the conversion mechanism used. This allows for a good estimate on any downtime that needs to be coordinated if this applies to the selected workload.

These tricks can make converting a large amount of storage a little less daunting. What tricks have you employed to tackle physical systems with large amounts of storage in the course of being converted to a virtual machine? Leave a comment below and let us know.

VDI planning primer on DHCP scope options

Fellow virtualization expert Andrew Kutz has argued that future virtual desktop infrastructure technologies (VDI) need to lose the desktop to truly advance VDI technology, and I agree. But until that time, we have to deal with VDI as it exists today. And that means accepting certain hurdles, which means accepting additional support requirements that today’s VDI poses. Let’s consider devices and their support requirements.The key to determining how virtual desktop infrastructure (VDI) devices interact with their connection broker is to identify the networking configuration. VDI devices use dynamic host control protocol (DHCP) scope options to get their configurations to the device that reflects where they go for the connection. Let’s dive into how the DHCP options are important to a VDI solution.

For starters, a DHCP scope option is a configuration that is defined on a networking server such as Windows Server’s DHCP server role. Traditional configurations for PCs and servers would have DHCP options such as subnet mask, default gateway and domain name server. VDI, however, allows the full range of DHCP scope options to be used. There are numerous scope options available for DHCP that are delivered to the requesting device in the acknowledgment message (DHCPACK), which is sent after the DHCP request message.

DHCP scope options vary by VDI device. Take for example the SunRay series of VDI devices. For VDI solutions in VMware implementations, the technology requires that at least DHCP options 49 and 66 are configured for connection to the Virtual Desktop Connector agent. Option 49 is for an X11 server window manager and 66 is a trivial file transfer protocol (TFTP) server for VDI device configuration files.

Beyond basic configuration, it may be worth tweaking some other network options based on the architecture of the VDI implementation. What has particularly caught my attention is a blog post by Sun’s Thin Client and Server Based Computing group, which points out that some environments may need to configure the maximum transmission unit (MTU) of network packets. This can also be assigned by DHCP and is of particular importance if the VDI implementation is to be a remote site with limited bandwidth. The default MTU of most configurations is around 1,500 bytes, yet performance may be better with a smaller number for maximum packet size from the endpoint VDI device. This and other factors make a fully representative pilot sound like a really good idea!

However, other platforms may use a new set of options to interact differently with the VDI device firmware. One example is the Pano Logic desktop device, which only requires the creation and configuration of option 001 as a vendor class. This is different than the example above in that there is no X11 window manager resident on the device.

While these DHCP configuration options are not overwhelming when viewed individually, it is worth considering the larger picture in the case of these options already in use. The most common example is an IP telephone at a remote site. While in central offices, IP telephony is usually split to a separate network, but this may not be the case for remote sites that have two or three VDI stations and the same number of phones. It may make sense to have only one IP network.

DHCP is critical to effective network management, including a VDI solution. Some planning on scope and configuration can go a long way to ensure that the technology will function as expected.

Making a P2V conversion: Stage-phase configuration

A well-documented procedure for physical-to-virtual (P2V) conversions still lacks the valuable information learned by experience. In this video blog, Rick Vanover introduces the stage configuration phase of a P2V conversion. When this phase and other phases of a conversion are used in a procedural manner, the success target will increase from accomodation of most scenarios that will arise in virtualization environments.

More on optimizing virtual hosts

Eric Siebert’s recent post on optimizing the host environment is a very important concern that may frequently be passed aside in the interest of reducing implementation time for virtual environments. In this blog, I would like to pipe in with a few of my own tips related to the host environment. These strategies are applicable to many virtualization platforms, and will transcend products as virtualization advances.

DNS configuration for the hosts
Having a correct DNS environment is important for all systems, not just virtual environments. Pay particular order to the suffix search order, as the first result for queries should be consistent and timely across hosts. Also, consider host entries for fixed systems, with an entry for the host itself, all other hosts, the management system and any other relevant systems with which the host would need to communicate. A specific issue is VMware’s DRS functionality, which can have issues with incorrect DNS configurations.

Time configuration for the hosts
For platforms that are Windows based and members of an Active Directory domain, this concern is somewhat eased. But for Linux systems, you want to have an automated mechanism in place to manage accurate time across hosts. For ESX and VirtualCenter, Eric again has covered this well over on SearchVMware.com with a tip.

Also decide whether you want guest virtual machines to sync time with the host via the driver software (VMware Tools, Guest Additions, etc.) This will relieve issues that go with multiple time zone support as well as separate issues in time synchronization.

Get environment agent notifications right
For virtualization hosts on the server level, all hardware failure notifications should be configured to the fullest extent possible. This can be device alerts (Dell DRAC/HP iLO), SNMP alerts, agent configurations or even blade server management software. With the scope of the virtual environment, maybe even use multiple notification mechanisms.

Single hypervisor per platform
This is more relevant on desktop environments, but it goes without saying that you should not install two products on a single system. Even though it may be tempting to have the functionality of multiple platforms, it may complicate the host environment. Take VMware Server and Sun xVM VirtualBox as an example, they theoretically could exist on same systems because of the VMware Bridge protocol binding and the VirtualBox explicit host adapters able to have their own configuration. This is one of those just-because-you-can-does-not-mean-you-should scenarios.

Host configuration is an area ripe for configuration procedures and policy enforcement to ensure consistent behavior among host systems. The procedural investment can usually help present the virtualization solution with more credibility as well.

Considering external-facing virtual machines

One of the more overlooked placement discussions that happen within the design or re-engineering phases of virtualization projects involves systems that are on an external network.

The placement of external systems can be addressed many different ways, including the use of virtual private network (VPN) authentication servers, web servers or remediation systems for network access control. Consider the following architecture diagram where larger virtualization hosts contain all types of systems within the virtualized environment:

While the networking of these virtual machines may be configured with the same protections as their physical counterparts, there are some concerns with this configuration. This can become even more of a concern in the event where the firewall is a virtual machine as well in the same environment. An architecture that can better protect the internal and external workloads would be to have a separate environment with connectivity and workloads only to the external interfaces. Consider the figure below for the same workload:

In this manner, more hosts may be needed for the same workload to account for maintenance mode and other factors when separated. These additional hosts may be configured with smaller hosts and smaller processor inventory to not incur any additional costs or licensing for anything that is licensed by processor.

If firewall or other core network appliances are virtualized, their placement requires a little more thought because they may have a footprint on both the internal and external networks. In the case of shared resources of internal and external workloads, an outbreak type event on an external system may have resources consumed at the expense of the internal workload. By having the internal and external workloads separated, the risk of attacks within the operating system or an attack that targets virtual machines would be initially contained by internal and external workloads.

This strategy can be applied to all virtualization products, and can also be applied more specifically to network and storage configurations to protect in the same fashion. 

Dissecting bridged-network functionality on Sun xVM VirtualBox for Windows

If you have not noticed, I have been on a Sun xVM VirtualBox kick recently. I think it is beneficial to virtualization administrators and managers to be familiar with at least two hypervisors — so why not learn more about xVM?

VirtualBox has a smooth interface for a version 1 release, but the one area that would require the most adjustment is the virtual networking. Let’s take a closer look at network functionality in VirtualBox.

Virtual networking on VirtualBox has a few key differences that VMware users would need to develop an understanding about before fully utilizing the potential of the product. The first difference is the concept of the virtual networking hardware. VirtualBox allows a virtual machine (VM) to have one of four network interface cards virtually assigned. These are the AMD PCNet PCI II, AMD PCNet FAST III, Intel Pro/1000 T and the Intel Pro/1000 MT. This array of virtual adapters allows a VM to have broad support for multiple operating systems, but the corresponding bridging functionality may make network administrators a little uneasy.

Spanning Tree
For Windows systems, VirtualBox uses a spanning tree algorithm from the native operating system bridging that may cause issues on systems with multiple interfaces in managed network environments. The bridged network functionality puts the VMs on the same physical network as the VirtualBox host system. In this fashion, a VM would be able to retrieve a DHCP network from the physical network and interact as if it were placed on the network parallel to the host. Windows XP and Server 2003 products’ bridging functionality is explained on the TechNet website.

Another key difference is that in order for a VM to use the bridged network is the addition of a bridging interface. Adding an interface is fairly straight forward with the use of the VBoxManage command. The following command would add a bridging interface named “VM-Bridge”:

VBoxManage createhostif "VM-Bridge"

Once this command is completed, the VM-Bridge interface is now present in the network connections inventory of the Windows control panel. Then a VM can be configured to use bridged networking with the newly created interface as shown in the figure below:

At this point, the VM-Bridge interface can transparently place the VM on the same network as the host when the Windows bridged connections are correctly configured. Note also that in the network configuration you can fully edit the MAC address of the VM. While exceptionally convenient, this can introduce risk for some environments and situations.

Now that we have gone through a quick look at VirtualBox’s implementation of bridging network connections for VMs, I would have to nudge the VMware products to be a little more seamless in the category of bridged networking. By having the VMware bridge protocol binding used instead of a separate series of adapters for the same purpose, VMware’s bridging fits better for most environments.

Make no mistake, the comprehensive VirtualBox networking implementation is fully competitive with VMware. There is much more to the VirtualBox networking implementation available for download in the online user guide in section 6.

Virtualization performance benchmarks needed ASAP, vendors say

Big players in the virtualization world griped about the absence of performance benchmarks for virtual machines on CIO Talk Radio yesterday and discussed some of the issues surrounding virtualization standards.

Guests on the show included: Simon Crosby, Chief Technology Officer of the Virtualization and Management Division of Citrix; Tom Bishop, Chief Technology Officer, of BMC Software; Dr. Tim Marsland, Sun Fellow, Chief Technology Officer, for the Software Organization at Sun Microsystems Inc.; and Brian Stevens, Chief Technology Officer and Vice President of Engineering at Red Hat.

The glaring ommission in this lineup: VMware, Inc.

The panelists on CIO Talk Radio didn’t mention VMware by name, but did complain that some companies aren’t being open with their performance data, thus prohibiting the virtualization industry from publishing comparative performance data.

VMware’s licensing agreement for ESX allows users to conduct internal performance testing and benchmarking studies, and allows those users (and not unauthorized third parties) to publish or publicly disseminate the data provided that VMware has reviewed and approved of the methodology, assumptions and other parameters of the study.

Users that have published benchmark data, like Sr. Systems Engineer Mark Foster did on his blog, have had to unpublish results because of VMware’s stipulations.

VMware introduced its own free benchmarking tool, VMmark, last year for certain applications.

Meanwhile, the SPEC Virtualization Committee has been working to create standard benchmarks for VMs. The committee’s goals are to deliver a benchmark that will model server consolidation of commonly virtualized systems such as application servers, web servers and file servers; provide a means to compare server performance while running a number of VMs; and produce a benchmark designed to scale across a wide range of systems.

SPEC expects these benchmarks to be available by the end of this year, but the timeline is not set in stone, according to the website.

Sun’s Marsland said benchmarking progress has been slow because there isn’t an easy way to define a workload, and a large number of benchmarks are required.

“We are talking about a virtual computer, with lots of aspects that need to be benchmarked,” Marsland said. “Every component that gets virtualized needs to be benchmarked.”

Having an open, standardized way of benchmarking is expected to push virtualization further into the mainstream because it will eliminate false perceptions about performance, panelists said. For instance, “there is the thought that I/O intensive workloads can not be virtualized, and the absence of benchmarks prevents us from proving otherwise. It is important for us to have good benchmarks out there,” one panelist on the show said.

Though users look at benchmarks, this type of data is most useful to vendors and OEMs who can use the performance standards to improve the technology, and of course, market their products.

“More open scrutiny of performance results will help us to improve as an industry overall,” Bishop said. “There are ways to measure performance in non-virtual environments, and people are adapting those techniques to get the most out of their virtualized environments.”

In terms of application performance in virtual environments, the issues differ depending on the data center infrastructure. The network, the servers and the storage all affect performance, said Stevens of RedHat.

“The areas that have to progress are around I/O. Intel and AMD are improving around page tables, and we will see improvements around I/O adapters soon,” Stevens said.

Another problem with virtualization? There are support challenges. If an application running in a VM starts acting wacky, the application vendor may not support it, Crosby said.

Licensing and support in virtual environments has been a major gripe with Oracle, for example, which does not support running its applications with VMware.

“It is a reasonable concern…right now there is irrational market based control. Some folks are abstaining from supporting certain apps [in virtual envionments]. As customers demand support, things will hopefully get rational, by next year I hope,” Crosby said.

Virtual environment architecting requires network zone placement

Almost every virtualization admin that I interact with has materially changed their strategy at some point with their first generation of server virtualization before the entire project is complete. Among the strategy changes are those related to network zoning, which will become a more important consideration as organizations approach higher levels of virtualization.

Specifically, the placement of external facing systems on the same virtual host as systems which house internal systems can put both sides of the network at risk if a compromise is made to the hypervisor from the external facing systems. This becomes especially important as the virtual appliance space allows organizations to easily consider firewall, intrusion detection, VPN and other external facing roles to be placed into the virtual environment as well as the frequent goal to virtualize everything.  

A more isolating strategy creates a separate environment with hosts dedicated to hosting virtual machines (VMs) that are external facing and not simultaneously host VMs on the internal network. While the hosts may be connected both to the internal and external networks in a DMZ network role, a compromise to the hypervisor or host system would not have as direct of an impact to the VMs running only on the internal networks. This also helps in emergency remediation by allowing a virtual host to be fully isolated or powered off until the issue is identified without impacting the internal network VMs.

When planning your next generation of server-side virtualization, consider the risks of placing internal and external network zones on resources that may contain external facing and internal only VMs. This type of architecture can bake in some inherent security into your environment that may save the day in the event of a zero-day vulnerability situation that affects the guest operating system or the virtualization hypervisor.

VKernel Capacity Bottleneck Analyzer for ESX virtualization available

Portsmouth, NH-based VKernel announced availability of its Capacity Bottleneck Analyzer Virtual Appliance, which allows system administrators to see capacity issues in VMware ESX Server-based environments so they can make necessary changes for optimum performance.

Network bottlenecks are issues in virtual environments due to increased capacity from virtual machines. A number of networking vendors have developed network products specifically for virtual environments to alleviate these issues.

A newer vendor called Altor Networks Inc. introduced a Virtual Network Security Analyzer last month that also lets IT view what is happening in virtual environment.

VKernel’s software monitors CPU, memory and storage utilization trends in VMware ESX environments across hosts, clusters and resource pools. The virtual appliance gives users a single-screen management dashboard that displays all of the details on capacity to help plan for new hosts, clusters and resource pools. Users can also receive alerts via email and SNMP.

The VKernel Capacity Bottleneck Analyzer Virtual Appliance is currently available with pricing starting at $199 per CPU socket.

Sun adds a connection broker to VDI offering

Sun Microsystems, Inc. announced this week it has added new features to its Virtual Desktop Infrastructure software, originally released at VMworld in September 2007, including Sun’s Virtual Desktop Connector (VDC).

Sun’s VDI 2.0 provides interfaces to PCs, mobile devices, and thin clients including Sun’s own Sun Ray thin client offering. With it, centralized desktops can be delivered through the LAN or WAN to Windows Vista, Windows XP, Mac OS X, Solaris or Linux on the desktop, which is fairly unique in the Windows-centric desktop market, said Chris Kawalek, Product Line Manager, Desktop & Virtualization Marketing, Sun Microsystems.

Sun’s VDC, meanwhile, is is more or less a connection broker that interfaces with ESX 3.5 and 3.0.x and Virtual Center Server 2.0.x and 2.5 (VMware infrastructure 3) to create pools of virtual machines that can be defined based on templates.

With Sun’s updated VDI offering, administrators can statically or dynamically assign users to specific VMs, either for a set number of days or indefinitely. Another feature is the ability to ‘reset’ end users’ virtual machines (VMs) if problems arise. For instance, if the user contracts a virus while on the web, the VM can be reset to a date before the issue occurred and operate as it did on that date, Kawalek said.

The tight integration with VMware virtualization software can be attributed to the OEM agreement Sun signed with VMware Inc. in February. Thus, with VDI 2.0, users can actively manage VMware virtual machines, but VMs from other vendors like Virtual Iron can only be statically created and assigned, Kawalek said.

Kawalek said Sun moved into the VDI space last year because it embodies Sun’s ‘the network is the computer’ message. Another reason? It’s the popular thing to do. “Everyone is very interested in centralizing their desktop environment, which is why vendors like Hewlett-Packard and VMware are in this space,” he said.

Sun’s VDI Version 2.0 became available March 18 at $149 per user, including one year of support. Sun Ray thin clients start at $249. Directions on how to install VDI 2.0 are available online, and a free trial can be downloaded from Sun’s website.