As Cloud Computing hits the mainstream, people are wondering: How mobile are my VMs?
I’ve had several people over the past few months ask me “I know I own my hosted virtual machines but how can I move them from one provider to another?” The short answer is that you can but it isn’t easy. Virtual Machines (VMs), often nearing the 100GB mark in size, are too large for traditional media, too large for quick transport via Internet lines and can’t be disconnected and physically carried from one location to another.
Let’s say that you’ve signed-up with a hosting service who’ll host your virtual infrastructure for you and you’ve built two dozen or so virtual machines in that environment. After several painful months of service, you decide to discontinue your service with that vendor and move to a different service — now what? How do you move your virtual machines? Do you move them at all or just delete them and start from scratch with the new vendor? Let’s examine this and other options available to you.
Since you have your own backups of your applications that you’ve placed on the hosted VMs, it shouldn’t be a problem to recreate a VM, install your apps and continue your service. Data, however, is another story. If your service hasn’t been a total disaster, you have valuable data that you need to keep and restore to the new service. Do you have backups of your data? Assume that the vendor makes no effort to backup your data unless you have that additional service specifically written into your hosting contract.
Starting over means that not only will you have to rebuild everything from a blank slate, you’ll also have to point your DNS settings to the new service, which is neither instantaneous nor without outage time. You’ll have to decide for yourself if you can weather the storm of starting over.
Perhaps you’ve decided that starting over is too risky, too painful or too expensive for you. Now you’ll move those VMs to another service provider. How will you go about it? Hopefully neither service will charge you extra for the bandwidth it requires to move huge VMs across their networks. Don’t count on their kindness, ask. Those two dozen VMs might represent several terabytes of data transfer and that won’t be cheap. It could also take days to perform a move like that and potentially leave your service down for a lengthy period of time while those transfers take place.
Should you decide to use the transfer method, keep both services up and running until you’re sure that the new one meets your expectations and that no glitches occurred during the file transfer.
In-House vs. Hosted
The next question that’s raised after starting over or moving VMs sounds less appealing is “Should I use a third-party hosting service at all or just bring my VMs in-house?” Actually, this option presents some of the same issues as the other two combined. You could setup your own in-house virtual infrastructure for moderate expense (Server hardware, power, networking gear, time). You could also either create your VMs from scratch or download them from your current provider. Either one you choose is going to be time-consuming and potentially expensive in terms of time and bandwidth.
In-house hosting offers some advantages over vendor hosting in that your service is fully customized by you and for you — no inflexible pre-packaged deals for you to conform to. Vendors want to lump everyone into a “Beat to fit; Paint to match” type of environment where customization is frowned upon with great disdain and expense.
Alternatively, using a hosting company can greatly relieve your stress by knowing (at least in theory) that your service will be up 100% of the time.
You own your VMs and where you host them is your business. However, when it comes to VM mobility, current technology leaves much to be desired. To prevent the need to mobilize your VMs, select a reliable, responsible and reputable vendor. How do you know? Ask around. Ask them. Google them. Maintain vigilance.
Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62