Information Technology Reference
In-Depth Information
vMotion Network Security
Whenever we design VMware networks, we always ensure that the vMotion network is separated
from all other tra c and, where possible, on a non-routed subnet. h e reason behind this design
decision is that vMotion tra c is not encrypted. h at's right; when a VM's memory is copied
between ESXi hosts, the tra c is sent in cleartext. h is might not be a concern for a lab or even a
development environment, but it certainly needs to be considered within a production or multiten-
ant environment. Let's look at a hypothetical situation involving a large bank.
A Bank-ESX i- 42a is an ESX i host w ith a VM running an SQL database. h is database holds custom-
ers' personal details, including credit card numbers. h e VM is secured behind multiple fi rewalls
and is far away from the Internet. Obviously, because of the sensitive nature of the data on this
server, it can be accessed by only a select number of senior administration staff to perform tasks
and maintenance. Because of these precautions, the bank considers this server to be “secure.”
h e more junior administration staff have access to the same management network but are specifi -
cally denied access to the more sensitive servers, such as this SQL database. One of the junior network
admins decides he wants access to the credit card information. He chooses to sniff the network tra c
on the management network to see if there's anything interesting going on. In most circumstances,
management tra c, such as the vSphere Web Client, is encrypted so the junior admin would get
only garbled data.
Unfortunately ABank-ESXi-42a needs to be put into maintenance and the vMotion network is
on the same subnet as the management tra c. h e vMotion for the SQL VM is initiated and the
database that resides in memory is sent in cleartext across the management network for the junior
network admin to see.
All the bank needed to do was segment the vMotion network onto an isolated VLAN or subnet
that only the vMotion VMkernel ports could access and this situation could have been avoided.
In addition to the coni guration requirements just outlined (shared storage and a vMotion-
enabled VMkernel port), a successful vMotion migration between two ESXi hosts relies on meet-
ing all of the following conditions:
Both the source and destination hosts must be coni gured with identical virtual switches
that are correctly coni gured, vMotion-enabled VMkernel ports. If you are using vSphere
Distributed Switches, both hosts must be participating in the same vSphere Distributed
Switch.
◆
All port groups to which the VM being migrated is attached must exist on both of the ESXi
hosts. Port group naming is case sensitive, so create identical port groups on each host, and
make sure they plug into the same physical subnets or VLANs. A virtual switch named
Production is not the same as a virtual switch named PRODUCTION. Remember that to
prevent downtime, the VM is not going to change its network address as it is moved. The
VM will retain its MAC address and IP address so clients connected to it don't have to
resolve any new information to reconnect.
◆
Processors in both hosts must be compatible. When a VM is transferred between hosts, the
VM has already detected the type of processor it is running on when it booted. Because
◆
