Detailed migration steps for Xen virtual machines _xen

You are already familiar with the installation of Xen virtual machines, but some are unfamiliar with Xen migrate operations. The friend who wants to know can refer to.

I. Preparations for the migration

Before migrating, there are a few preparations to do, primarily the destination host and the source host and its network. The following are described separately.

First, both the source and destination hosts must run both the Xen and Xend daemons. You must ensure that the destination host has sufficient disk space, memory capacity, and resources for the migrated domain to run. In addition, the source host and destination host must also have the same architecture and virtualization extensions, for example, if the source host is using a x86-64 architecture with virtualized extensions, so must the destination host. This is done to prevent situations where domain migration does not work because the instruction set used by the kernel and the user library does not match.

Second, on the network, the source host and destination host must also be on the same subnet. When migrating domain, if the destination node is on a different subnet, the migration will fail because the Mac and IP address of domain is migrated as well. If you run a firewall, you may need to create the appropriate iptables rules to allow incoming connections.

Furthermore, when migrating, the Xend daemon aborts domain from running on the source host, replicates it to the destination host, and then restarts the domain. By default, the Xend daemon accepts migration requests from the native computer. In order for the migration target to accept incoming requests from a remote host, you must modify the Xen-relocation-hosts-allow parameters of the destination host in the/etc/xend-config.sxp file. Because no certification is provided, you must qualify the host that is allowed to migrate for security reasons.

Below, we begin with the first method for migrating domain: The storage restore method.

Second, storage restore migration method

The process of storing the Restore method is as follows: First, save the current state of a domain to a file on your hard disk, and then xend the file to restore the original state of the domain. In fact, this is very similar to a laptop's hibernation function: When hibernating, the laptop saves the image of the hard drive state and then shuts down automatically. When you quit hibernation, it restores the system to its previous running state using a saved disk image.

In this section, we'll explain how to save a running domain as a file, then use it to restore domain to its previous working state, and where to restore it, either on the same server or on a Xen server outside. However, before you can save domain as an image file, make sure to free up the disk space sufficient to hold the file.

Operation Process

OK, so let's start with the steps to migrate domain on a Xen server. The specific thing to do is to create a Debian domain and then save its state to a file that will be used to restore this Debian domain.

1. Create Debian Guest domain:

# XM Create Debian_etch_domu.cfg–c

2, check whether the domain is operating normally. Because we provide the-C parameter to the above XM command, this will start client domain in the current console. However, to check if this domain has started, you must use a different console session.

3, we will save the current state of this domain to the/xen-saved-images directory, of course, can also be saved to the other directory you choose:

# XM Save 1/xen-saved-images/etch.save Source virtual machine is closed

4, the saved domain will be removed from the currently running domain list, we can use the XM command to list the current running domain, to see if it has been deleted.

5, from the file restore saved domain:

# XM Restore/xen-saved-images/etch.save

6. Execute the XM command again, and we will see that the restored domain is back in the current domain list.

Related instructions

When the running state of domain in the work is saved to a disk file, the file is not encrypted in any form, so the malicious user can tamper with these images as long as they can access the directory of the saved image files. Therefore, it is important to ensure that access to the folders hosting these images is secure.

The running state of domain is the snapshot or image of the domain at the moment of being saved. The information and status of all running processes are stored in this file. When you view the file, you will see that this is a large binary that is equal to the amount of memory used by the domain when it was saved. Because Xen domain usually runs some enterprise applications, this file is generally small, usually around a few gigabytes or so. Therefore, you must ensure that there is sufficient storage space to store this file. Although this example keeps the state on top of a hard disk file, you can also store the file on a large enough network folder, or even a USB drive. It's really nice to save domain to a USB drive so you can carry it around and restore it on different servers when you need it.

We can use the XM command plus the restore option to restore the stored domain, which starts the domain again and restores it to its state when it is saved. When using a storage restore method, there are a few things to keep in mind: Because the ID in domain restore is different from the domain ID for its save time, you must be aware of the change in IDs when using XM to view the restored domain. Although domain is restored to its original state (the state of the stored moment), it cannot automatically connect to the console in that domain, instead, we must explicitly run the XM command to connect to the console.

Although this is a simple way to migrate domain, it is important to note that since domain was deleted from active domain when it was saved, the various services running on that domain could not be used or accessed. If you are unable to accept this business interruption, you should consider the Xen dynamic migration features described in the next section

Iii. Dynamic Migration Method

Above, we describe the storage restore method when migrating domain on a xen server. Although this approach is simple, if you have a critical business that is not interrupted on your server, or if you want to minimize business interruption times, you still cannot take this migration approach.

At this point, Xen also provides us with a powerful feature to be useful, it is the dynamic migration method. It allows domain to migrate domain to another Xen server at the expense of minimal service disruption during runtime.

Using Xen dynamic migrations is a great advantage, and the main advantages are listed below:

· Xen's dynamic migration, along with high-availability solutions such as heartbeat, can bring us a "never-anchored" system. The latest version of Enterprise SuSe Linux Server and red Hat Enterprise Linux is also leveraging Xen to provide a variety of high-availability solutions. You can easily meet the stringent requirements of a variety of services while ensuring that all critical business services are not interrupted.

• It enables us to maintain a physical server hosting a virtual machine in a "cure-not-ill" manner. You can monitor the server and then move the system to resolve potential and suspicious problems immediately.

• It makes it possible to achieve load balancing across multiple servers, enabling us to make better use of all computing resources in the enterprise so that it is optimally utilized. It is to be noted that the Xen open source version does not currently support the ability to automatically migrate dynamically when a fault is DOM0 on the sensor.

• It makes it easier to add computing power to the system configuration when needed.

• You can replace the hardware as needed without interrupting the service running on that hardware.

Only know the benefits of dynamic migration is not enough, now introduce the specific use of methods.

Requirements:

1. Both must be running with Xen and Xend daemons
2. You must ensure that the destination host has sufficient disk space, memory capacity, and resources
3. The source and destination hosts must also reside on the same subnet
4. The source and destination hosts must also have the same architecture and virtualization extensions

Configuration file:

[Root@host1 ~]# Vi/etc/xen/xend-config.sxp
(Xend-relocation-server Yes)
(Xend-relocation-port 8002)
(Xend-relocation-address ')
(Xend-relocation-hosts-allow ')
Re-execution:/etc/init.d/xend restart

Specific operations

First, introduce the servers involved in dynamic migration, which are:

hosta: A Linux NFS server that provides storage space for xendomain over the network.

HostB: A Xen host server that uses an NFS exported directory to run a client Domain:ubuntu Fuwa.

HOSTC: A Xen host server that is a migration destination for client domain, Ubuntu Fuwa, from the HOSTB server.

The following figure shows us the specifics of the configuration

⒈ dynamic migration requires shared memory. In reality, in addition to the requirements in the first section, the minimum speed of the network requirements is 100MB. To share the memory, we will build an NFS server on the Xen host at the top of the image above, and the domain to be migrated uses the shared memory space on the NFS server.

⒉ Edit the/etc/exports file, add the following line to export the storage directory:

#/xen-storage * (R,sync,no_root_squash)

⒊ Save the file and restart the Server for NFS. Add an NFS server to the server's service and set it to run when the system restarts:

# Service NFS Startchkconfig NFS on

⒋ we will build two Xen servers and let them use the storage provided by Server for NFS. In order to mount the exported directory, you need to add installation points for all two Xen servers:

# Mount Hostb:/xen-storage

#-Mount Hostc:/xen-storage

⒌ Modify the Xend configuration file to allow dynamic migration. Edit the/etc/xen/xend-config.sxp file and make sure that the following two lines are not commented out:

(Xend-relocation-port 8002)
(Xend-relocation-address ')

The effect is to start the Xen daemon to listen and respond to various requests for dynamic migrations.

⒍ builds a Xen domain running on server Storage for NFS and starts the client domain on HOSTB. and have the client domain use the following configuration:

Cat >/home/pchaganti/xen-images/ubuntu_fuwa_nfs_domu.cfg << "EOF"

Kernel = "/boot/vmlinuz-2.6.16.38-xenu"
Memory = 256
Name = "Ubuntu_fuwa_nfs_domu"
Vif = [' ip=192.168.1.111 ']
Nfs_server = ' 192.168.1.67 '
Nfs_root = '/xen-storage '
root = '/dev/nfs '
Eof

⒎ now, we have a client domain running in HostB, which is stored using an NFS exported directory. We can run the following command on the HOSTB to check that domain is running correctly:

⒏ Next, we will dynamically migrate this client domain to the HOSTC server, which may take several minutes. If the migration fails, a message indicating a failure is displayed in the console.

# XM Migrate--live ubuntu_fuwa_nfs_domu HOSTC

⒐ above is all the work of moving domain dynamically to another Xen server! Now using the XM command to display domain that is currently running on both the HOSTB and HOSTC servers, you will find that the migrated domain is currently only found on the HOSTC server. Listed in domain that is running on the HOSTB server, no shadow of migrated domain has been found.

Related instructions

Dynamic migration is the process of moving a virtual machine from one physical host to another in a "live" situation. This process does not have a noticeable impact on the end user, enabling the administrator to perform offline maintenance or upgrades of the physical server without affecting the user's normal use.

It is important to note that to change the location of domain, you must modify the default xend configuration file. Also, to make the modifications take effect on the host, you must restart the host on which the Xen server resides. We need to modify the following configuration:

· Xend-relocation-server: This flag is used to enable/Cancel the Server migration feature. By default, this flag is set to No, which is not allowed to change the location of the server. During the migration process, domain virtual memory becomes the original form without any encryption. Therefore, be careful when you enable this option on an untrusted network.

· The Xend-relocation-port:xend daemon migrates through this port. The default value for this port is 8002.

In addition, there are two parameters that need not be modified to be aware of when migrating in an enterprise deployment environment:

· Xend-relocation-address: This flag restricts the migration of domain to a specific interface. The specified address is the interface address that listens for inbound connections for domain migration. This flag is only used when the Xend-relocation-server parameter is enabled.

· Xend-relocation-hosts-allow: This flag defines the host that is allowed to communicate with the migration port. The value is a sequence of regular expressions separated by a space. If the value is empty, then all input connections are allowed, otherwise the value will either match an IP address or match a full domain name

In fact, the migration process from HostB to HOSTC is divided into phases, as follows:

First stage: before migration.

At this time, Fuwa domain runs in HostB, and is an active domain.

Second stage: Book.

Issue a migration request on the HOSTB, and then check and confirm the resources available on the HOSTC. Xend then prepares a VM container on the HOSTC at the required size. If Xend can't get the resources they need on HOSTC, then it's over. The domain is still running on HOSTB, as if nothing had happened, and this migration attempt has been abandoned.

Phase III: Duplicate pre-copy.

Transfer all memory pages from HostB to HOSTC, and then continue to transfer the pages that changed during the previous transfer. Eventually, the pages are copied to the HOSTC.

By the third phase, Fuwa domain is still functioning normally on HOSTC.

Phase IV: Abort and copy.

Domain that is running on HOSTB is suspended and all network traffic is redirected to HOSTC. At the end of this phase, in addition to having a pending domain on the HOSTB, the HOSTB has a copy of this suspended domain. At this point, the HOSTB domain can also be used as the original copy, in case this step fails, it can also resume operation on HostB.

Phase Fifth: Delivery.

If there is no error or failure in this step, HOSTC sends an indication to HOSTB that it already has a domain image that is completely consistent with HOSTB. HostB will now remove the domain from its Xen server. From this point on, HOSTC will become the first host in this domain.

During phases fourth through fifth, Fuwa domain is in an outage state.

Phase sixth: Activation.

Activates the migrated domain on the HOSTC. All device drivers within the domain are now associated with the new machine. At this point, Fuwa domain again in the HOSTC resurrection.

These steps are done behind the scenes, and it is this series of obscure operations that allows migrations to be so smooth and seamless!

Iv. concluding remarks

In this chapter, we study two ways to migrate Xen client domain: storage reduction method and dynamic migration method. The previous method is similar to a portable computer's deep sleep, which stores the captured domain run status as an image on disk before restoring the domain with that image. The latter approach dynamically changes the running location of domain in the running state with minimal disruption and downtime. The combination of these two migration methods will make virtualization technology more efficient.