From April 2017, Mammoth Cloud will begin migrating all VPS currently located on our Xen infrastructure to our KVM infrastructure. This document explains what this means, why we are doing it, and the specific changes you can expect as part of the migration.
The document is organised starting with a high-level overview and getting progressively more technical as we move through the various aspects of the migration.
How does this affect my VPS?
The migration process requires a short outage of between 5 and 15 minutes. Migrations will be scheduled between 0:00AM and 6:00AM AEST to minimise the disruption to your service.
We will send an email with a specific time and date for your server to be migrated at least seven days ahead of the scheduled outage.
This migration will not change any of the following things:
- Your server's IP address
- Your plan configuration (e.g. number of processors, memory, storage)
- Your disk contents
As part of this migration you will also receive a permanent upgrade to faster hardware.
At the completion of the migration your server will have been rebooted. We highly recommend checking your VPS after the migration to ensure all essential services (e.g. web server, SMTP, database) have started correctly during the boot process.
What are Xen & KVM exactly?
Xen and KVM are two different software packages that are used to provision "virtual" servers - that is, they provide the mechanism to securely split a physical server running Linux (the "host node") into multiple, smaller virtual servers.
Both Xen and KVM are mature, widely supported software packages and are utilised by thousands of companies around the world.
Mammoth has been using Xen for this purpose since our service launched in 2010. In 2015 we introduced KVM as an alternative during signup, and in 2016 we removed the ability to purchase a VPS on our Xen infrastructure.
Why migrate to KVM?
In the two years that we have been running both Xen and KVM, we have observed that KVM provides a number of benefits over Xen:
- KVM is the "native" Linux virtualisation solution, while Xen is an add-on product. New features tend to be available in KVM first, and in our estimation has broader support from the developer community.
- We have found KVM to provide better availability over the long term (i.e. less unscheduled outages)
- Our testing on identical hardware shows KVM holds a slight edge in VPS performance, particularly for disk I/O
From an administrative point of view
What improvements does the KVM infrastructure provide?
Our KVM infrastructure is newer and benefits from more recent hardware along with the design and architectural improvements we have made as the service has grown. Some of the improvements include:
- KVM provides for live-migration, which allows us to perform scheduled maintenance on host nodes without requiring an outage on your VPS.
- Our Virtual Private Cloud facility is available only on KVM. Once a Xen VPS has been migrated to KVM, it may be added to either a new or existing VPC network.
- Full range of the latest operating system images if you choose to re-install.
- The disk performance is better, with 100% Intel SSD
- The hardware is newer; in particular the memory speed is increased providing better performance.
- Full 10gbit LAN provides for faster internal communication and backup/restore time.
- It is physically located in NextDC S1 datacentre with improved physical security compared to the datacentre holding our Xen infrastructure.
- It utilises a broader range of IP transit providers, providing for faster access and less interruptions.
- The network is protected by automated null-routing of DDoS traffic, while the Xen infrastructure requires manual blocking by the service provider.
How does the migration process work?
Mammoth will send you an email notification of a pending migration at a minimum of seven days prior. This email will specify the time and date that the migration will begin along with an estimate duration.
Migrations are completed on a server-by-server basis, so if you have multiple VPS at Mammoth Cloud you will receive one email per server. Migrations will be completed in an internally-defined order that does not correlate with customer accounts, so there may be a significant period of time between individual server migrations.
At the start of an individual server's migration process, we will take a snapshot of your current VPS disk and transfer that snapshot to our KVM infrastructure. During this transfer your VPS will remain online and will function normally.
At the completion of this snapshot transfer, we will shutdown your VPS (i.e. it will be powered off). While the power is off, we will synchronise any changes that were made to your VPS disk after the earlier snapshot was taken. Typically the synchronisation process takes less than a minute.
Once the disk is synchronised, we will make the modifications necessary for your VPS to boot correctly under KVM. Depending on the particular operating system you are using on your VPS, this modification process takes between 2 and 10 minutes.
In the final step we will boot your VPS on the new KVM infrastructure and begin monitoring the server for network activity. Once the server is active, the migration is marked as successful and the process is complete.
In the unlikely scenario that network activity is not seen within a few minutes, the migration process will automatically abort and restart your server on our Xen infrastructure. If this happens we will contact you after determining the fault so that we can reschedule the migration.
What modifications are required to boot on KVM?
KVM requires different network and disk drivers to Xen, which depending on the operating system your VPS is using may either require installation or re-configuration to enable. We have prepared separate articles that cover the changes in detail:
I have multiple Xen servers that communicate over the LAN?
While the KVM migration is occurring we will provide a layer-2 network bridge between the two environments. This means that two servers will be able to communicate without routing (i.e. a single "hop" in traceroute) even where one server has been migrated to KVM while the other remains on Xen.