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.