VMware one-ups Microsoft with vSphere 5.1
New vMotion capabilities make it easier to move VMs
The race for virtualization dominance between Microsoft and VMware has become
more interesting with VMware's recent release of vSphere 5.1. We obtained
vSphere around the same moment as the final release of Windows Server 2012,
whose newly included virtual switch and enhanced Hyper-V features were designed
to clobber VMware.
But back in the garages of their digital "brickyard", VMware was scheming to
one-up the one-ups.
While we like Hyper-V3, there are both pronounced and subtle reasons why we like
vSphere 5.1 a little more. Some of the competitive difficulties amount to
classic Microsoft problems revolving around support for competitive platforms.
But VMware also does a better job trying to lift the barriers to virtualization
via annual aggressive releases.
The trump card of this release is the ability to move a virtual machine from one
machine and storage space to another. If your use of virtualization is small,
this release won't make much difference to you. But if you need optimizations or
have an appreciation for moving VMs around as though they were almost toys,
vSphere 5.1 does it.
The vSphere 5.1 specs are statistically awesome and yet esoteric. At the upper
end, vSphere is capable of controlling a 1TB VM, or symmetrical multiprocessing
(SMP) with up to 64 processors. We don't know of any commercial hardware that
supports either of these.
The vSphere 5.1 pricing model was changed at VMworld to a more simplified model
revolving around processors/cores, but it's still the priciest virtualization
that we know of. It still has warts, but there has been much plastic surgery and
lipstick applied, as well -- the face of a new web UI.
Included in the vSphere app kit is an updated Distributed Switch. The switch now
supports more controls, including Network I/O Control (NetIOC) for admittance
controls, IEEE 802.1p tagging for QoS/CoS flows, and enhanced vocabulary for
Cisco and IBM virtual switches. There is increased monitoring capability for the
switch, both in-band and out-of-band, and many of the changes reflect control
capabilities that are suited towards 10Gigabit Ethernet.
We setup a local and VPN-connected network running several hardware servers thru
a 10G Ethernet Extreme Networks Summit X650 (locally) and between our lab and
network operations center connection. The reason? The vMotion software will jam
an equal number of pre-bonded virtual and physical ports with a traveling
virtual machine during VM movements. More ports, higher speed, means a faster
movement from one metal server to the target host for a moving VM.
VMware
We started up configuration on a bare metal HP DL560 Gen8 server. This server
has plentiful, even spectacular power and serious disk in a 2U frame, and uses
what we believe to be pretty standard drivers. But VMware's vSphere 5.1 lacked
drivers for it, so it hung with an indiscernible error message. We recognize
that we received early, yet not beta, supposed-to-be-production code, so we
contacted VMware and within a few hours, we had a custom-cut of 5.1, and from
there, everything moved splendidly.
Of the subtle upgrades, this edition is able to use more complex authorization
and certificate trading schemes, and still has an ongoing affinity for
authentication with Microsoft Active Directory. However, instead of the
Windows-only client, we could now use browsers from Windows, MacOS and Linux.
The UI is understandable and makes comparatively good use of browser windowing
areas.
Our older vSphere Clients were immediately subject to a download of a new client
type when we used them to access 5.1 turf, and managing a combination of 5.0 and
5.1 resources requires the 5.1 denominator of vSphere client -- which looks
superficially identical to the old one. When we started looking to resources and
configuration, we rapidly found newer features.
We wanted to test moving a VM from one machine to another, Storage vMotion-style,
whose target didn't share the same storage. This means that the instance has to
move its IP information, its storage basis, its work, and even its CPU-type
on-the-fly
We moved it, although it required some initial work. We're used to the minutiae
of setting up a VMware network, and little of that has changed. We provision our
networks through ISO images that we store on an NFS network. Using NFS is still
not without its pain on VMware, as initial boots from ISO images into VMs --
even when we've pre-built and pre-seeded images, require comparatively obscure
setups.
The upshot is that if you pre-configure Linux and Windows Server VMs (we tested
Windows 2008 R2 and Windows 2012 gold release), you can envelop them in what
amounts to a virtual wrapper that isolates them (largely) from machine-specific
settings. This means that ISOs can conceptually be "hatched" into instances that
are "wrapped" with settings that allow them to be moved and manipulated more as
true virtualized object instances than was possible before.
Hosts still need vMotion or Storage vMotion (the new secret sauce) to permit
live migration across hardware. But VM instances become more atomic, keeping
their functionality intact and are nearly immune to their external hosting
environment's characteristics or even geography. They live in isolation, doing
their work, and while they aren't ignorant of their external settings, the
settings are a convenience -- they're plugged into sockets, very "The
Matrix"-like.
Once we accessed a vSphere 5.1 host, our vSphere 5.0 client was updated
automatically, and didn't give us much of a choice about the location of where
the new vSphere client was going to reside, an installer inflexibility.
Nonetheless, we installed the new client and obtained access immediately to our
host VM platforms.
It's probably best at this point to install the vCenter Server Appliance (vCSA)
locally to allow it to access resources remotely. Missing this step caused us
delays.
Using vSphere 5.1 client, we wanted to deploy an OVF template that installs the
VMware vCenter 5.1 Server Appliance (VCSA). The server appliance also holds the
optional web UI, and is a management control center for vS51 installations. The
VCSA uses a template file (OVA and OVF files that describe the procedure), and
two VMware Virtual Disks (VMDK) -- four separate files in total.
The OVA/OVF template files execute and deploy from the client-local resources
including http/https/ftp and local disks/shares. We used an NFS share controlled
by our newly updated vSphere 5.1 client in the lab. The NFS files are about 70
miles away.
This was a mistake on our part, as the vSphere 5.1 client initially dragged the
.OVF, .OVA, and the two VMDK files associated with the vSphere Server Appliance
out of our NOC cabinet servers, across the Internet to the lab, where it
dutifully then sent them back across the Internet to the target ESXi 5 host that
we'd just brought up. The vCenter 5.1 client warned us: 149 minutes remaining;
in reality, it took longer, about three hours. Locally, it would have taken
perhaps a half hour.
This misery is obviated if one installs the Server Appliance locally. Remote
execution would have been more handy, but as the VCSA does this, it has to be
installed first.
The VCSA features are updated from the 5.0 version and offer more configuration
options, especially authentication and database options. We could use an
internal database to keep track of settings and configurations, or use an
external database (Oracle was recommended). MS SQL Server can't be used, and we
wondered why an open source database product wasn't offered for embedded
tracking. The appliance is based on SUSE Linux 11, and it uses 4GB of memory and
8GB of disk. A non-monstrous installation ought to be more easily tracked with
an internal LAMP-ish database product.
The VCSA can stand alone, or be synced with others in "Linked Mode,'' which
requires authentication through Active Directory, and allows inventory views in
a single group. Linked Mode VCSAs can't have vMotion migrations, however, which
frustrated us.
Moving needles between haystacks
In the old model, VMware's vMotion allowed moving VMs, hot/live, between hosts
if the hosts shared the same storage. VMware's Storage vMotion removes the
limitation of requiring the same storage -- if other small constraints are
respected, including the maximum number of concurrent vMotions of any type that
can be handled. VMotions aren't encrypted, however, and so VMware recommends
(and we agree) that Storage vMotions (and normal migrations) need to be in
wire-secure environments.
The maximum number of concurrent migrations is often a function of network
traffic capability. We could bond several 10GB ports together to maximize
transfer and minimize downtime of hot/alive VMs, but on a network with
congestion, or networks using VLANs, things could slow as VMs are tossed around.
There are also limitations imposed on data stores that can be manipulated -- a
function of the version of ESX or ESXi in play.
Using a Gigabit Ethernet network, Storage vMotion of a sample Windows 2008R2 VM
took 11 minutes with two bonded 10G Ethernet ports and a back-channel
connection. Linking all three available ports actually slowed things down (16
minutes), as the back channel seems to be necessary for traffic management
during v-movements. But we had finally proven the concept. Numerous bonded 10G
Ethernet ports would have likely shortened the process of live migration more
quickly.
We moved a VM from the lab location through the Internet, to our cabinet at
nFrame. Our local network connection is variably throttled by Comcast, and so we
won't quote overall migration time. Let's just say it was a very long time.
Nonetheless, it worked.
Storage vMotion removes one large VM movement problem by allowing, conditions
permitting, VM movement and/or replication to "foreign" (if licensed) hosts.
High availability within a data center is increased, as is the ability to
optimize host CPU cycles by match-fitting VM workloads with host spare-cycles.
The Distributed Switch appliance and 10G Ethernet ports can make all the
difference. Slower links make Storage vMotion less practical. It's our belief
that VMware will sell, by accident, more 10G Ethernet switches.
Increasing high availability through the use of rapid failover to an alternate
cabinet, room or even cross-country site is a direct function of communications
bandwidth and managerial strength in terms of concurrent migration operations
capability. For now, even if all the hypervisor hosts are licensed and running
the latest version of VMware with fully configured Storage vMotion, there are
upper-end practical limits to how much and how frequently VMs can be
moved/migrated.
How We Tested
We tested vSphere 5.1 on an existing network consisting of two sides, lab and
NOC. The lab is joined to the NOC at nFrame in Carmel Ind., by a Comcast
Business Broadband link into a Gigabit Ethernet connection supplied by nFrame.
At the NOC at nFrame are several HP, Dell, and Lenovo hosts connected by an
Extreme Networks 10GBE X650 crossbar L2/L3 switch.
We installed freshly or upgraded various hosts with vSphere, as well as client
machines, then installed the vCenter Server Appliance as described, and
subsequently used this installed appliance as our access method to the converted
vSphere5.1 hosts. We installed several trial VMs from scratch, and two (Windows
2008 R2 minimal configuration VMs) to be used in a trial of Storage vMotion
between hosts, as described. We also noted features of the web client, and
overall changes between supported features between vSphere 5.0 and 5.1.
NAVIGATE:
12 essential Windows 8 keyboard shortcuts 