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.
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}'
Moving disks can take some time, so ensure that you have plenty of time available. Perform the following steps:
~]# 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.
~]# virsh undefine <guestname>
~]# virsh blockcopy --domain <guestname> --path <original path> --dest <destination path> --wait --verbose –-pivot
~]# virsh define /tmp/<guestname>.xml
~]# virsh vol-delete --pool <poolname> --vol <volname>
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:
blockjob --abort
or actually switched over to the new target by executing the blockjob --pivot
commandThe 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