On 1/12/07, Bill Denney <denney@xxxxxxxxxxxxxx> wrote:
[...]
This is not the same. Migrations are for moving without downtime. P2V
is just what it says, moving physical to virtual.
But, as I said, this migration without downtime premise is, in my
opinion, only possible with either virtualization that supports live
migration, or with a high availabilty setup for your services.
I can imagine they could try something like moving the disk over to a
VM, boot it, and at some time start to tunnel all IP requests to the
new machine.
But, as you see in their own video, they need at least one windows
reboot before the copied system really works. Imagine that would be a
database server you are trying to migrate with "no downtime". This
server will have quite some important data changes in this time, after
copying the disk, and before the virtual system is restarted and
requests can be tunneled to it.
So,what you get is data loss and inconsistencies.
Maybe my idea of "no downtime" is wrong. For me it means:
All services on the machine are fully accessible with no performance
loss and reachable under the same DNS name, IP address, and port
before and after the migration. Running transactions are not rolled
back, but continued on the new system. No outside system or human
realizes the switch and needs to change it's behaviour to use the
continued service.
* Maintain a stable system. If a system has been stable for months or
years without needing significant modifications, do you really want to
mess with that.
If you don't know exactly how to reconstruct your system in the
desired and needed state you have a desaster waiting to happen at some
random moment. Better get to know your system now than having to
find out how to reconstruct it when the system breaks at some much
less desireable time.
* Unable to reinstall. What if a system has software from a company
that went out of business and the tech before you broke the only
installation CD for the software or there is an online requirement to
installing the software and their website doesn't exist.
That _might_ be the only reason I can accept especially the very last
one. On the other hand, in this bad situation you should have even
more interest in finding out how this system can be rebuilt or to find
a software that replaces the unsupported, uninstallable stuff ASAP.
* Save time. Why take hours of human time when it can be done in
minutes of human time (though still possibly hours of computer time).
Again: Better invest a few days now, and know your systems, than save
some time now, and be forced to find out how to reconstruct it some
random moment.
These are just the ideas off the top of my head for why you may want to
do a P2V migration.
As you see, I am still very sceptic about these ideas, and I have real
trouble to imagine how a tool could migrate my system with "no
downtime" without knowing a lot about it's inner workings.
For sure, in special cases it can be useful from a business
perspective to buy a license for such a tool (e.g. you need to migrate
now, not in two days or a week), but in general, I believe the way to
go is a generic HA setup and automatic installation that serves as
documentation of the system install at the same time. (and regular
test installs to ensure that your install server config really builds
working systems).
Henning
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|