Fergenschmeir had implemented a dedicated network segment for iSCSI traffic, both to reduce bandwidth consumption of front-end segments and to enable jumbo frames. This iSCSI segment wasn’t routed, however, which presented some problems here. When running with iSCSI, VI3 annoyingly requires that the primary interface of the physical server and any dedicated iSCSI NICs have access to the iSCSI target in order to handle auto discovery. The network admin added this route in the core switch, and after we configured the VI3 host with the proper iSCSI target address, that 600GB LUN was suddenly visible. Notwithstanding the extra step during setup, the iSCSI support in VI3 is handled nicely, and it definitely performs well.

Download PDF

• VMware's virtual infrastructure

The Bottom Line VMware Infrastructure 3 VMware, vmware.com Excellent  8.8 criteria score weight Manageability 8 25% Scalability 9 25% Usability 9 25% Setup 9 15% Value 9 10% Cost: Pricing per two sockets: Starter, $1,000; Standard, $3,750 (includes Virtual SMP); Enterprise, $5,750 (includes Virtual SMP, VMotion, DRS, and HA) Platforms: ESX runs on Intel- and AMD-based server hardware and supports Windows, Red Hat Linux, Suse Linux, Sun Solaris, and Novell NetWare OSes. Bottom Line: VI3 reinforces VMware’s standing as the leading virtualization platform vendor. Plenty of new features including iSCSI support and Distributed Resource Scheduler, as well as improved performance, will grease the wheels of server virtualization in enterprise datacenters. VI3 does have rough edges, including the absence of 10-Gig support, but overall it’s a hit. About our Reviews and Scoring Methodology

Migratory Patterns
With the first VI3 server built and ready for action, we could begin the first of our five P2V (physical-to-virtual) migrations. To handle these migrations, we used VMware’s P2V Assistant and a beta release of VMware’s new Converter product. In terms of architecture, these two tools couldn’t be more different.

P2V Assistant is based on an old Knoppix Live CD, which is booted on the source server. When (and if) all storage and network devices are discovered and configured, you can use a text-based menuing system from the source server console to migrate the server to a VM on a specific destination server. Interestingly, given its Linux roots, P2V Assistant has an easier time with Windows servers than Linux servers, and with newer server hardware than older gear. P2V Assistant had trouble detecting the RAID and NIC hardware in our Dell PowerEdge 2950 and 850 servers, but flawlessly inventoried an HP ProLiant DL360 G3. The migration from physical to virtual took only about 10 minutes, and correctly resized the destination disk, necessary because the source server had more than 60GB of unused space in the primary partition. As soon as the migration was finished, we booted the new VM and powered off the old server. Other than the downtime caused by booting the domain controller from the CD, we encountered no other problems

For the next migration, we put the new VMware Converter tool to the test. This tool offers both live and offline migration options. The live version runs as a stand-alone application on a Windows server. For this test, the Microsoft Exchange Server 2003 system was selected for migration. Converter has a simple interface that allows admins to supply a Windows server name or IP address and log-in credentials, modify settings for the destination VM, and optionally resize partitions. After that, it’s simply a matter of clicking a button to convert the server. During the course of the conversion, we added several users and Exchange mailboxes to the domain to see how complete a live conversion could be under normal operations. In production, you wouldn’t want to migrate any servers running databases, e-mail, or other data­centric tasks in this way, but it was a good opportunity to test the thoroughness of the tool. Of the three users added to the Exchange server, the first two, which were added during the first half of the migration, were present in the resulting VM. The last user, added when the migration was 85 percent complete, was present in Active Directory but missing a mailbox. In addition, the Exchange services failed to start when the Exchange Server VM was initially booted, but they did start manually, and the server appeared to suffer no ill effects from the migration. This form of P2V is certainly attractive, because it requires no real downtime, but should be used only in cases of largely quiescent servers, or for servers with static tasks, such as Web servers and file servers with external storage.

We also tried Converter’s offline mode. As with P2V Assistant, this requires booting the server from a CD into a limited OS. Unlike P2V Assistant, however, Converter’s CD is built on Windows PE, a curious decision. Converter required far more time to boot than the Linux-based P2V Assistant, and it didn’t offer any better hardware detection.

The next migration was the Fergenschmeir file server, a white-box server built from spare parts. Because the CD-based methods weren’t likely to recognize the mishmash of hardware, this server was migrated live with VMware Converter. On top of the live migration, we put the server under heavy load at the time, pushing nearly 100MB per second to simulated users. There was even a third wrinkle to this plan: the bulk of the files being served were residing on an iSCSI LUN.

This scenario presented two obvious options for conversion: Migrate the data on the iSCSI LUN into a VMware disk image, or simply map the LUN straight through to the resulting VM. Both options would retain the storage on the iSCSI SAN, but the second would permit the LUN to be bound by other servers. It turned out that VI3 also offers a middle route here, which is to wrap the existing iSCSI LUN in a virtual disk layer. To configure this, the LUN must be visible from all VI3 hosts, and the new disk built for the VM selected with Virtual Disk Mode, which adds the virtualization layer.