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 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.

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