Detailed migration steps for the Xen virtual machine

You are familiar with installing the xen virtual machine, but some are not familiar with the xen migrate operation. If you want to know more about your friends, please refer to 1.

1. Preparation for the migration

There is some preparatory work to be done before the migration, mainly on the destination and source hosts and their network aspects. These are described below.

First, the Xen and xend daemons must be running on both the source and destination hosts. You must ensure that the destination host has enough disk space, memory capacity, and resources to run the migrated domain. In addition, the source and destination hosts must have the same architecture and virtualization extensions, for example, if the source host is using an x 86-64 architecture with virtualization extensions, the destination host must have the same architecture. This is done to prevent situations where domain does not work properly after the migration due to a mismatch between the kernel and the instruction set used by the user library.

Second, on the network side, the source and destination hosts 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 addresses of the domain will also be migrated. If you are running a firewall, you may need to create the appropriate iptables rules to allow inbound connections.

Furthermore, when migrating, the xend daemon aborts domain running on the source host, copies it to the destination host, and then restarts the domain. By default, the xend daemon accepts migration requests from the native. In order for the migration target to accept a migration request from a remote host, you must modify the xen-relocation-hosts-allow parameter of the destination host in the file /etc/ xend-config.sxp. Because authentication is not provided, you must qualify which hosts are allowed to migrate for security reasons.

Next, let's start with the first method for migrating domain: storage restore.

2. Storage and restore migration method

The stored restore method works like this: first, the current running state of an domain is saved to a file on the hard disk. Then, Xend USES this file to restore the original state of the domain. In fact, this is very similar to the sleep function of a portable computer: when it is asleep, the portable computer will save an image of the state of the hard disk and then automatically shut down. When it exits hibernation, it USES the saved disk image to restore the system to its previous running state.

In this section, we show you how to save a running domain to a single file and then use it to restore domain to its previous working state, either on the same server or on a separate Xen server. However, before saving domain as an image file, 1 must free up enough disk space to hold the file.

The operation process

Ok, let's start with the steps to migrate Domain on the Xen server. To do this: create an Debian domain and save its state to a file that will be used to restore the Debian domain.

1. Create Debian guest domain:

xm create debian_etch_domU. cfg, c

2. Check whether the domain is running normally. Because we provided the -c parameter to the xm command above, this will launch client Domain in the current console. However, to check if the Domain is started, you must use another console session.

3. We are going to save the current state of Domain to/xen-saved-images, or of course to any other directory of your choice:

xm save 1 / xen-saved-images/etch.save source virtual machine shut down

4. The saved Domain will be deleted from the list of Domain currently running. We can use the xm command to list Domain currently running and see if it has been deleted.

5. Restore the saved Domain from the file:

# 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 you save the running state of Domain at work to a disk file, the file is not encrypted in any way, so a malicious user who has access to the saved image file directory can manipulate the images. Therefore, it is particularly important to secure access to the folders where these images are stored.

The running state of an Domain is a snapshot or image of the Domain at the time it was saved. The information and status of all running processes are stored in this file. When you look at this file, you will see that it is a large binary file, the size of which is equal to the amount of memory used when the Domain was saved. Because Xen Domain usually runs some enterprise application, this file is no smaller than GB. Therefore, you must make sure that you have enough storage space for this file. Although this example keeps the state on top of a single hard disk file, you can also store this file in a network folder that is large enough, or even on an U disk. It's nice to save Domain to U disk, so you can carry it around and restore it to a different server when you need it.

We can use the xm command plus the restore option to restore the stored Domain, which will start the Domain again and restore it to the state it was saved in. There are a few things to be aware of when using the store restore method: since Domain restored ID is different from Domain ID at the time of its save, 1 must pay attention to the changes of ID when using xm to view the restored Domain. Although Domain is restored to its original state (the state at which it was stored), it is not automatically connected to the domain console. Instead, we must explicitly run the xm command to connect to the console.

While this migration of Domain is simple and easy, it is important to note that since Domain was removed from active Domain at the time of saving, the various services running on Domain are no longer available or accessible. If you are not comfortable with this kind of business interruption, you should consider adopting the live migration feature of Xen described in the next section

3. Dynamic migration method

Above, we described the storage restore method for migrating Domain on an Xen server. While this approach is simple, if you have critical business on your server that cannot be interrupted, or if you want to minimize business interruption time, you still cannot use this migration approach.

At this point, Xen also provides us with one powerful feature that comes in handy: live migration. It enables Domain to migrate Domain to another Xen server at the cost of minimal service outages during run time.

There are many benefits to using Xen for live migration. The main advantages are listed as follows:

· the live migration of Xen works with high availability solutions such as heartbeat, giving us a "never anchored" system. The latest versions of Enterprise SuSe Linux Server and Red Hat Enterprise Linux also leverage 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 the physical server hosting the virtual machine in a "cure" manner. You can monitor the server and then move the system to resolve potential and suspected problems on the fly.

· it makes it possible to load balance across multiple servers, enabling us to better utilize all computing resources in the enterprise to optimize their utilization. It is important to note that the open source version of Xen does not currently support the ability to automatically perform live migration when a fault is detected on dom0.

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

· you can change hardware as needed without interrupting services running on that hardware.

It's not enough to know the benefits of live migration, but let's look at how to use it.

Requirements:

Both must run the Xen and xend daemons You must ensure that the destination host has sufficient disk space, memory capacity, and resources The source and destination hosts must also be on the same subnet The source and destination hosts must also have the same architecture and virtualization extensions

Profile:

[root@host1 ~]# vi /etc/xen/xend-config.sxp
(xend-relocation-server yes)
(xend-relocation-port 8002)
(xend-relocation-address '')
(xend-relocation-hosts- allow '')
To perform: / etc init d/xend restart

Specific operation

First of all, I will introduce the servers involved in dynamic migration. They are:

· hostA: one linux NFS server providing storage space for XenDomain over the network.

· hostB: 1 Xen host server running 1 client Domain: Ubuntu Fuwa using the directory exported by NFS.

· hostC: one Xen host server, which is the migration destination of the client Domain or Ubuntu Fuwa from the hostB server.

The following figure shows the configuration

Dynamic migration requires Shared storage. In reality, with the exception of the requirements in section 1, the minimum speed required is 100MB. For Shared storage, we will set up an NFS server on our Xen host at the top of the figure above. The Domain to be migrated will use the same Shared storage space on the NFS server.

Edit /etc /exports file by adding the following line to export the memory directory:

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

Save the file and restart the NFS server. Add the NFS server to the server's services and set it to run when the system is restarted:

# service nfs startchkconfig nfs on

4. We will set up two Xen servers and give them access to storage provided by the NFS server. To mount the export directory, you need to add installation points for both Xen servers:

# mount hostB:/xen-storage

#- mount hostC:/xen-storage

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

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

Its role is to start the Xen daemon to listen for and respond to various requests for live migration.

Pictures of a run on NFS server memory on Xen Domain, and on hostB launch the client Domain. 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

But now, we have a client running in hostB Domain, it USES NFS export directory for storage. We can run the following command on hostB to check if the Domain is running properly:

⒏ next, we will be the client Domain dynamic migration to hostC server, this may take a few minutes. If the migration fails, a message indicating the failure is displayed in the console.

# xm migrate --live ubuntu_fuwa_nfs_domU hostC

⒐ is above will running Domain dynamic migration to another 1 Xen server all the work! Now use the xm command to display Domain currently running on hostB and hostC servers. You will find that the migrated Domain is currently only available on hostC servers, and no trace of the migrated Domain can be found in the listed Domain server running on hostB servers.

Related instructions

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

Note that to change where Domain will run, you must modify the default Xend configuration file. In addition, for the changes to 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 server migration. By default, this flag is set to no, which means that the location of the server is not allowed to change. During the migration, Domain virtual memory will become in its original form without any encryption. So be careful when enabling this option on an untrusted network.

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

In addition, there are two parameters that do not need to be modified, and one to note when migrating in an enterprise deployment environment:

· Xend-relocation-address: this flag restricts the migration of Domain to a specific interface. The address specified is the interface address that listens for incoming connections for the 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 migrated port. The value is a sequence of regular expressions separated by Spaces. If the value is empty, then all input connections are allowed; otherwise, the value matches either 1 IP address or 1 full domain name

In fact, the migration process from hostB to hostC is divided into several stages, as shown below:

Stage 1: before migration.

At this point, Fuwa Domain is running on hostB and is an active Domain.

Stage 2: reservations.

Make a migration request on hostB, then check and confirm the resources available on hostC. Then, Xend prepares an VM container in the required size on hostC. If Xend is unable to obtain the required resources on hostC, then the cut ends. The Domain still runs on hostB, and as if nothing had happened, the migration attempt was abandoned.

Stage 3: repeat the precopy.

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

As of phase 3, Fuwa Domain is still operating on top of hostC.

Stage 4: abort and copy.

Domain running on hostB is suspended and all its network traffic is redirected to hostC. At the end of this phase, in addition to the one suspended Domain on hostB, a copy of the suspended Domain is also available on hostB. At this point, the suspended Domain on hostB can still be used as the original copy. When the first step of 10000 fails, it can resume running on hostB.

Phase 5: delivery.

If there are no errors or failures in step 1, hostC sends an indication to hostB that it already has an Domain image corresponding to hostB exactly 1. Now, hostB will delete the Domain from its Xen server. From this point on, hostC will be the first host of this Domain.

During phases 4 through 5, Fuwa Domain is in an outage state.

Phase 6: activation.

Activate the migrated Domain on hostC. All device drivers inside the Domain are now associated with the new machine. At this point, Fuwa Domain was resurrected on hostC.

These steps are all behind the scenes, and it is the quiet operation of the 1 series that makes the transition so smooth and seamless!

4. The conclusion

In this chapter we examine two ways of migrating Xen client Domain: storage restore and live migration. The first method is similar to the deep sleep of a portable computer, in that it stores the captured domain run state on disk as an image, and then restores the domain using that image. The latter method dynamically changes the running position of domain in the running state with minimal interruption and downtime. The combination of these two migration approaches is sure to make virtualization even more effective.