From Apple's latest version of its pro-level laptop to Amazon's entrance into the wireless earbuds market, here's the kit we got out hands on in November. ...
Caption by: Roger Howorth
Launched in September, esxMigrator from Vizioncore lets server administrators migrate virtual machines (VMs) from servers running the VMware ESX Server 2.x virtualisation platform to those running VMware’s flagship ESX Server 3, part of VMware’s recently launched Virtual Infrastructure 3 (VI3) package of server virtualisation tools. Given that VI3 is cheaper than its predecessor and has better features, this is an upgrade that most businesses running VMware are likely to perform sometime soon.
Vizioncore says the expected lifetime of esxMigrator is likely to be short -- once companies have migrated their systems to VI3, they will no longer need esxMigrator. However, the process of migrating VMs without such a tool is relatively slow and labour-intensive, so Vizioncore expects a lot of esxMigrator sales over the coming months.
Prices start at £537.63 (ex. VAT), which covers the migration of 25 VMs at a single site, ranging up to a multi-site licence costing £4,032.26 (ex. VAT), for companies with a large number of ESX Servers and VMs to migrate. So at around £25 per migration, the price is probably less than it would cost for server administrators to perform the task manually.
The software must be installed on a Windows 2000 desktop or server, or later, that has the Microsoft .NET Framework 1.1 and Microsoft Data Access Components 2.8 installed. EsxMigrator also requires a LAN connection to at least two ESX servers -- one running ESX 3 and one ESX 2.x. The product is not designed for companies that are upgrading a single ESX 2.x system to VI3. We installed the tool on a Windows XP Professional desktop that was already configured with VMware’s VI3 Client software and Vizioncore’s esxRanger Professional backup tool for VMware servers. The installation took around ten incident-free minutes.
Once installed, we needed to enter the fully qualified domain names of our ESX 2.x and VI3 servers. EsxMigrator then retrieved a list of VMs that could be migrated from the ESX 2.x servers, and discovered details about the VI3 server that would be needed for migrations, such as a list of its storage volumes and network interfaces.The highlighted VM in the VI3 client window was migrated using esxMigrator.
EsxMigrator has options to automatically switch off a source VM after migration and switch on its ESX 3 replacement. Although this would result in some downtime, depending on how quickly the migrated VM boots up, this downtime could be as little as one or two minutes.
Consequently, esxMigrator can also be configured so that the switch-over from source to target VM happens at a scheduled time, so that any downtime occurs at a quiet period. Beyond that, there are remarkably few options for users to worry about. The tool is driven from a single graphical display, which shows ESX 2.x VMs grouped by the server on which they reside. We configured esxMigrator to move a single VM by selecting it from the list, and using various drop-down boxes to select options such as the target VI3 server, and the datastore and networks to use on the VI3 target. We then pressed the Migrate button, which causes a pop-up menu with a few last options to be displayed. Clicking OK on this panel launched the migration process.esxMigrator is driven from a single window listing VMs that can be migrated in the top left panel.
In our tests, it took 22 minutes to migrate a VM from one host to another over a 100Mbps LAN. The VM had a 5.9GB virtual disk that was 75 percent full, and the VM was up and running on the source server throughout the migration process. Apart from the option of switching it off after copying, the source VM is untouched by the migration process, and in our case we opted to leave it running. Once migrated, the new VI3 copy of the VM is converted to the latest VI3 virtual hardware, which means that server administrators are immediately able to take advantage of VI3 features such as the ability to make 32 snapshots of the VM, and to upgrade its hardware to the VI3 maximum of 4-way SMP with 16GB of RAM. Migrating VMs manually would require the virtual hardware to be upgraded manually, which could mean additional delays before the new VM could be brought online.
Caption by: Roger Howorth