Shulou(Shulou.com)06/01 Report--

This article mainly introduces "how to solve the problems of KVM virtual machine migration in Linux system". In daily operation, it is believed that many people have doubts about how to solve the problems of KVM virtual machine migration in Linux system. The editor consulted all kinds of materials and sorted out simple and useful operation methods. I hope it will be helpful for you to answer the question of "how to solve the problem of KVM virtual machine migration in Linux system"! Next, please follow the editor to study!

Let's cut the crap and get to the point (the migrated machine is sourceVM, the server is source, and the target server: target,# is followed by the shell command)

Experimental environment:

RedHat 6.2

The code is as follows:

# virsh version

Compiled against library: libvir 0.9.4

Using library: libvir 0.9.4

Using API: QEMU 0.9.4

Running hypervisor: QEMU 0.12.1

There are mainly two ways, command line virsh migrate and graphical interface virt-mamge

The command line is relatively simple:

The code is as follows:

# virsh migrate sourceVM qemu+ssh://target/system-live

(if the port of ssh is not 22 by default, it can be written as qemu+ssh://target:port/system)

No.1 Question::

Error: internal error hostname on destination resolved to localhost, but migration requires an FQDN

The solution is simple, because the hostname is localhost by default, and we need to modify the target's hostname, which is also possible temporarily.

The code is as follows:

# hostname target

No.2 Question:

Error: internal error Attempt to migrate guest to the same host 00020003-0004-0005-0006-000700080009

Daniel says it is the problem of the server provider in this mail list.

You can check this ID with # dmidecode-s system-uuid, which in theory is # virsh sysinfo | grep uuid and # virsh capabilities | grep uuid

These three ID are the same. (the solution posted in the forum before is to download a file of dmidecode command to replace the system to achieve the purpose of modification, but today I just modify the configuration file of libvirt, which may be a problem with the version.)

Let's modify the configuration file of libvirtd

The code is as follows:

# sed-I "/ # host_uuid/ahost_uuid =\" `uuidgen`\ "/ etc/libvirt/libvirtd.conf

Restart the libvirtd service

The code is as follows:

# / etc/init.d/libvirtd restart

And then check again.

The code is as follows:

# virsh capabilities | grep uuid

No.3 Question:

Error: unable to set user and group to '107 on' / image/sourceVM/disk.img': No such file or directory

If you get into this step smoothly, it will be very simple. You can create one directly without directory.

Note: the created disk should be the same size (larger should be OK) and format (raw or qcow2) as that of the source virtual machine.

No.4 Question::

Error: Unable to resolve address' target' service '49155: Name or service not known

"" Name or service not known "" I believe we all know how to solve this, / etc/hosts. Skip

When you execute the migration command again, there will be almost no error. My experimental environment is, if you have any other questions, please reply, thank you.

Virtual machine migration is directly related to the bandwidth of the network and the size of virtual machine images, but online migration should be most concerned about downtime. The method I tested is to ping target the server all the time, pausing for about 1 second.

Graphics is relatively simple, dealing with the same FQDN mentioned above, in addition to the same UUID, is the problem of ssh authentication when establishing a connection.

In my environment, we must add ssh authentication when using virt-manage to connect remotely, and log in once at the terminal to record the information of the server to the target machine's ~ /. Ssh/knows (in fact, there is an interface for yes/no to enter yes)

After the connection is established, right click on the machine and have an option of Migrate.

Pop up the target server for migration, select the target server, and click Migrate

That's about all the problems with migration.

The rest are some small details about migration and other things:

There are basically three types of vnc listening ports when setting them.

127.0.0.1 (default): only local access, that is, virt-mange and virt-view

Host_ip: all machines except the local machine can access it.

0.0.0.0: a collection of the above two

When migrating, the listening address needs to be changed to 0.0.0.0, and the port is automatically assigned to-1, because if nothing happens, the specified port will conflict!

If you don't have the .ssh / directory, you may not be able to do authentication-free (no real environment, I don't know why). It doesn't matter, we can use tcp instead of ssh to connect to the target server.

The methods are as follows:

1 modify / etc/libvirt/libvirtd.conf

[/ code] listen_tls = 0

Listen_tcp = 1

Tcp_port = "16509"

Auth_tcp = "sasl" [/ code]

2 remove the comments of LIBVIRTD_ARGS= "--listen" in / etc/sysconfig/libvirtd

3 modify the listen in / etc/libvirt/qemu.conf to 0.0.0.0, remove the password comment

4 run the following command to add users

The code is as follows:

# saslpasswd2-a libvirt admin

Password: xxxxxx

Again (for verification): xxxxxx

You can view the users that have been created with the following command

The code is as follows:

# sasldblistusers2-f / etc/libvirt/passwd.db

Fred@t60wlan.home.berrange.com: userPassword

5 restart the libvirtd service ok!

Original quote: BLOG of xiaoli110

Select tcp in the location of the ssh. If the port is not modified, the port can be left empty.

You can use # virsh-c qemu+tcp://target/system list when testing the connection

Another question is, can I pull the server when I migrate? Most of the normal migration is pushed, just like scp and rsync, it is possible to migrate by pulling virtual machines.

To migrate the virtual machine to the server, previously, it had to be two identical Cpu. Today, when I was testing, I found that I could migrate from source to target, and when I came back, there was a problem. When I found that sourcce was missing some instruction sets, it can also be migrated for cpu that doesn't make sense, but the target server must contain all the instruction sets of the source server cpu.

At this point, the study on "how to solve the problem of KVM virtual machine migration in Linux system" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.