By default, KVM (libvirtd) images on Ubuntu and most other Linux distributions are found in /var/lib/libvirt/images. This can be inconvenient if you don't have a separate /var partition that can grow over time to accommodate multiple large images.
You can simply rename the images folder to something else and then symlink to a larger space with it (e.g. ln -s /data1/libvirt/images /var/lib/libvirt/images). That's what I used to do.
But that can lead to all sorts of unanticipated trouble. The right way to have your images on a bigger disk is to change the path for libvirt's default storage pool to a partition on that big disk, which is logically where KVM is going to create them.
First check to make sure a default pool exists:
$ virsh pool-list --all
Name State Autostart
-------------------------------
default active yesNOTE: If no default pool exists, follow the instructions in this gist to create one on your preferred storage volume.
Assuming a default pool exists, find the current default pool's path:
$ virsh pool-dumpxml default
<pool type='dir'>
<name>default</name>
<uuid>91c6d1b3-4e42-4a1f-989e-89b2127da056</uuid>
<capacity unit='bytes'>133070688256</capacity>
<allocation unit='bytes'>25177309184</allocation>
<available unit='bytes'>107893379072</available>
<source>
</source>
<target>
<path>/var/lib/libvirt/images</path>
<permissions>
<mode>0711</mode>
<owner>64055</owner>
<group>108</group>
</permissions>
</target>
</pool>Before going further it is best to shut down ("destroy") all existing virtual machines).
Now use virsh edit to change the disk path in each virtual machines's configuration to the default pool's new location. Assuming this will be "/data1/libvirt/images", you would proceed like this:
$ virsh edit example
...
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
- <source file='/var/lib/libvirt/images/example.qcow2'/>
+ <source file='/data1/libvirt/images/example.qcow2'/>(the line will then read <source file='/data1/libvirt/images/example.qcow2'
Next, the default pool should be completely shut down:
$ virsh pool-destroy default
Then, undefined:
$ virsh pool-undefine default
NOTE: By default, virt-manager creates additional pools automatically for things like iso files. These should also be destroyed and undefined before proceeding, to free things up for redefining the default pool (if you don't, the system will spit out "error: operation failed: Storage source conflict with pool" messages when you try redefining).
Now, recreate the default pool anew and start:
$ virsh pool-define-as default dir --target "/data1/libvirt/images"
$ virsh pool-build default
$ virsh pool-start default
$ virsh pool-autostart defaultCheck the status with virsh-info:
$ virsh pool-info defaultAnd then the configuration with pool-dumpxml:
$ virsh pool-dumpxml defaultFinally, move any existing disk images from /var/lib/libvirt/images to the new location (e.g. /data1/libvirt/images).
If someone wants to move where lots of space is going to get allocated, then that most likely means referencing a different partition such as when /var was allocated to a small SSD that's too small for all the qcow2 files (VM's) intended to be created.
virsh pool-dumpxml default >default-pool.xml Drags along the UUID and space characteristics of the default partition. If the intent is to move the default to a different partition, then reusing the default-pool.xml without also changing the partition information including those space characteristics, probably isn't a good idea. How does one get those space characteristics accurately and do they get rewritten over time by the system to keep those stats updated?
What's the proven safe procedure for immediately moving where KVM wants to put files to something like /vms on a clean partition instead of burying it deep into /var before a single VM has been created? In lots of instances, KVM is added to an old already used system.
Burying a space hog deep into /var doesn't sound like a good idea.