On Jun 18, 2009, at 11:45 PM, Edward Ned Harvey wrote:
Not sure how much this will help, but - I barely see the point of
"migration" as it were.
One beautiful use of it is to migrate your VMs from HOST_A to HOST_B,
upgrade the firmware, install ESX patches, perform hardware
maintenance on HOST_A, etc., then migrate everything back. Repeat over
the course of your entire VMware farm.
ESX actually has, if you have DRS (Distributed Resource Scheduling)
enabled, the ability to, in conjunction with the Update Manager,
figure out which ESX hosts need updates, shuffle your running VMs to
other servers, put the ESX server in maintenance mode, upgrade it,
reboot it, and when it comes back online, bring it out of maintenance
mode, and shuffle VMs back onto it so it can proceed on to the next.
In so doing, it can quickly - and without customer impact - upgrade
your entire cluster to the latest version of ESX, say.
Migration is all about "zero downtime". Now that's not necessarily
important for every environment (in fact, we're in process of moving
our web frontend VMs to standalone ESXi hosts that don't have the
enterprise licensing that allows Vmotion, because it's architected
such that "we can lose a ESX server's worth of web servers without
complaint" to do maintenance.
But for the VMs that aren't "horizontally scaled", migration is a
godsend.
In order to do a live migration (without shutting
down the VM) both heads must have access to shared storage where the
VM
resides. That is - the VM must reside on disk on a SAN.
(or a NAS).
That being said - if it's ok to shutdown the VM, then anything is
possible.
You can get VMWare Server for free (runs on Windows Server, or
Linux) and
you can simply copy/move the VM files from one computer to another.
This
way, even just using free software, you can easily migrate your VM
from one
set of hardware to another. I've done this before - and - there's a
slight
fib here. I needed to text-edit a config file in the VM directory.
Supposedly this extra step is not needed if you're using ESX. I
hear (but
have not personally done) that ESX can shutdown the VM, migrate it,
modify
the config file as necessary, and start it up again at the
destination in
essentially a single click.
ESX doesn't require editing files at all. You can do two different
types of migrations in ESX:
"Live" Migration, a/k/a VMotion - The running VM's memory and state
are transferred to another unit in your ESX farm and on an appointed
moment, the new ESX server simply "takes over" for the old one. This
requires shared storage of some sort (SAN/NAS).
"Cold" Migration - With ESX this is simply a matter of clicking the
"Migrate this VM to another host" link. If you are using shared-
storage it will go fairly quickly as the only data that changes hands
between the ESX servers is some metadata about "who owns that VM". If
you're using local storage on each ESX host, then it'll have to
transfer your entire disk from one to the other.
Also - Since you say you're running Ubuntu - It isn't officially a
supported
OS (at least in vmware server & workstation - perhaps different in
ESX?)
Ummm, yeah it is... and seems to have been for a while:
http://tinyurl.com/mlunll
_______________________________________________
Discuss mailing list
[email protected]
http://lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
http://lopsa.org/
