Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases now! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Red Hat Enterprise Linux Server Cookbook

You're reading from   Red Hat Enterprise Linux Server Cookbook Over 60 recipes to help you build, configure, and orchestrate RHEL 7 Server to make your everyday administration experience seamless

Arrow left icon
Product type Paperback
Published in Dec 2015
Publisher
ISBN-13 9781784392017
Length 250 pages
Edition 1st Edition
Tools
Concepts
Arrow right icon
Authors (2):
Arrow left icon
Jakub Gaj Jakub Gaj
Author Profile Icon Jakub Gaj
Jakub Gaj
William Leemans William Leemans
Author Profile Icon William Leemans
William Leemans
Arrow right icon
View More author details
Toc

Table of Contents (12) Chapters Close

Preface 1. Working with KVM Guests FREE CHAPTER 2. Deploying RHEL "En Masse" 3. Configuring Your Network 4. Configuring Your New System 5. Using SELinux 6. Orchestrating with Ansible 7. Puppet Configuration Management 8. Yum and Repositories 9. Securing RHEL 7 10. Monitoring and Performance Tuning Index

Moving VMs

Moving disks will mitigate the risk of failing disks. When your CPUs, memory, and other non-disk-related components start failing, you have no other option but to move the guests to other host(s).

The recipe for this task is rather simple, but it's the prerequisites that can make it succeed or fail miserably.

Getting ready

The prerequisites for this recipe are quite extended.

For the host, the following are the requirements:

  • You'll need to have access to shared data. Both the source and destination KVM machine will need to be able to access the same storage—for example, iSCSI, NFS, and so on.
  • Both hosts need the same type of CPU—that is, Intel or AMD (one cannot live migrate a guest from a host with Intel CPUs to a host with AMD CPUs).
  • Both hosts need to be installed with the same version and updates of libvirt.
  • Both hosts need to have the same network ports open.
  • Both hosts must have identical KVM network configurations or at least the same network configurations for the interfaces used by the guest.
  • Both hosts must be accessible through the network.
  • It's a good idea to have a management network set up and connected to the two hosts, which can be used for data transfer. This will cause less network traffic on your "production" network and increase the overall speed.
  • The No execution bit must be the same on both hosts.

The requirement for the guest is:

  • The cache=none must be specified for all block devices that are opened in write mode.

How to do it…

There are multiple ways to migrate hosts, but we will only highlight the two most common ways.

Live native migration over the default network

This process to migrate a host is luckily very simple and can be summarized in one command.

On the source host, execute the following:

~]# virsh migrate --domain <guestname> --live –-persistent --undefinesource --verbose --desturl qemu+ssh://<host 2>/system

Live native migration over a dedicated network

It is possible to perform the migration over a dedicated network. By default, this will use the first network it finds that suits it needs. You'll need to specify the listening address (on the host) and the protocol. This requires the same command as before, but we'll need to specify the local listening IP address and protocol, such as TCP.

On the source host, execute the following:

~]# virsh migrate --domain <guestname> --live –-persistent --undefinesource --verbose --desturl qemu+ssh://<host 2>/system tcp://<local ip address on dedicated network>/

How it works…

This type of migration is called a "hypervisor native" transport. The biggest advantage of this type of migration is that it incurs the lowest computational cost by minimizing the number of data copies involved.

When we migrate a host, it performs a copy of the memory of the guest to the new host. When the copying is successful, it kills the guest on the source host and starts it on the new host. As the memory is copied, the interruption will be very short-lived.

There's more…

Communication between the two hosts is over SSH, which is already pretty secure. However, it's also possible to tunnel the data over an even more strongly encrypted channel by specifying the --tunnelled option. This will impose more traffic on your network as there will be extra data communication between the two hosts.

The --compress option can help you out if you wish to reduce the traffic over your network, but this will increase the load on both your hosts as they need to compress/decompress the data, which, in turn, may impact your guests performance. If time is not of the essence but traffic is, this is a good solution.

See also

There's very good and in-depth documentation about this process at https://libvirt.org/migration.html.

You have been reading a chapter from
Red Hat Enterprise Linux Server Cookbook
Published in: Dec 2015
Publisher:
ISBN-13: 9781784392017
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime