Book Image

Red Hat Enterprise Linux Server Cookbook

By : Jakub Gaj, William Leemans
Book Image

Red Hat Enterprise Linux Server Cookbook

By: Jakub Gaj, William Leemans

Overview of this book

Dominating the server market, the Red Hat Enterprise Linux operating system gives you the support you need to modernize your infrastructure and boost your organization’s efficiency. Combining both stability and flexibility, RHEL helps you meet the challenges of today and adapt to the demands of tomorrow. This practical Cookbook guide will help you get to grips with RHEL 7 Server and automating its installation. Designed to provide targeted assistance through hands-on recipe guidance, it will introduce you to everything you need to know about KVM guests and deploying multiple standardized RHEL systems effortlessly. Get practical reference advice that will make complex networks setups look like child’s play, and dive into in-depth coverage of configuring a RHEL system. Also including full recipe coverage of how to set up, configuring, and troubleshoot SELinux, you’ll also discover how secure your operating system, as well as how to monitor it.
Table of Contents (17 chapters)
Red Hat Enterprise Linux Server Cookbook
Credits
About the Author
About the Reviewers
www.PacktPub.com
Preface
Index

Moving disks to another storage


Moving disks around is part of the life cycle of a guest. Disks in the storage pools (local or network) may fail or fill up due to bad capacity management. Another reason may be the cost or speed of the disks involved. Sooner or later, one of these things will happen, and then you will need to move the storage somewhere else.

Ordinarily, one would have to shut down the guest, copy the storage volume file elsewhere (if it is a file), wait, update the machine's XML configuration, and launch it again. However, in today's mission-critical enterprises, this may not always be possible.

Getting ready

In order to perform this copy, you need the source and destination paths of the disk. You can get the source path by checking the XML configuration file or, even better, by querying the storage volume itself. This does require you to know which storage pool it is located on.

Execute the following command:

~]# virsh vol-list --pool <storage pool> |awk '$1 ~ /^<volume name>$/ {print $2}'

Ensure that your destination is an existing storage pool; if not, go ahead and create it.

Check out the Configuring resources recipe in this chapter to create storage pools.

If you can't remember the path to your pool's location, run the following:

~]# virsh pool-dumpxml <poolname> |awk '/<path>.*<\/path>/ {print $1}'

How to do it…

Moving disks can take some time, so ensure that you have plenty of time available. Perform the following steps:

  1. Dump the inactive XML configuration file for the guest, as follows:

    ~]# virsh dumpxml --inactive <guestname> > /tmp/<guestname>.xml
    

    The –-inactive file will ensure that it doesn't copy any temporary information that is irrelevant to the guest.

  2. Undefine the guest through the following command:

    ~]# virsh undefine <guestname>
    
  3. Copy the virtual disk to another location by executing the following:

    ~]# virsh blockcopy --domain <guestname> --path <original path> --dest <destination path> --wait --verbose –-pivot
    
  4. Now, edit the guest's XML configuration file and change the path of the disk to the new location.

  5. Redefine the guest, as follows:

    ~]# virsh define /tmp/<guestname>.xml
    
  6. Remove the source disk after you are happy with the results. Run the following command:

    ~]# virsh vol-delete --pool <poolname> --vol <volname>
    

How it works…

The moving of disks can only be performed on transient domains, which is the reason we execute the virsh undefine command. In order to be able to make it persistent again after the transfer, we also need to dump the XML configuration file and modify the storage volume path.

Moving the disk does two things, which are:

  • Firstly, it copies all the data of the source to the destination

  • Secondly, when the copying is complete, both source and destination remain mirrored until it is either canceled with blockjob --abort or actually switched over to the new target by executing the blockjob --pivot command

The preceding blockcopy command does everything at the same time. The --wait command will not give control back to the user until the command fails or succeeds. It is essentially the same as the following:

~]# virsh blockcopy --domain <guestname> --path <source path> --dest <destination path>

Monitor the progress of the copy by executing the following:

~]# watch -n10 "virsh blockjob –domain <guestname> --path <source path> --info"

When it's done, execute this:

~]# virsh blockjob –domain <guestname> --path <source path> --pivot

There's more…

It is also possible to change the disk format on the fly, by specifying the --format argument with the format that you want to convert your disk into. If you want to copy it to a block device, specify --blockdev.