I have the following setup on my host

[root@fake ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              32G   30G  785M  98% /
tmpfs                  12G   76K   12G   1% /dev/shm
/dev/sda1             504M  103M  376M  22% /boot
/dev/sda4             1.6T   63G  1.5T   5% /project
/dev/sr0              3.0G  3.0G     0 100% /media/UDF Volume

Since I am running out of space on /root, I'd like to move my virtual machines over to /project if possible, and create all new ones from there. Moving them shouldn't be too much of an issue once the second is solved -- I cannot figure out how to instruct KVM to store the virtual machine image that would be created with a new VM) on /project instead of /root, where KVM is installed.

Is there any way to store the virtual machine images on different partition than KVM itself?


Add the disk to the KVM Storage pool. I use virt-manager, but I'm guessing virsh can do this too. Via virt-manager, for the new VM, edit, choose "Connection Details". Open the Storage Tab. Click the + button to add a storage pool, and select the type of storage. I believe you want filesystem.

  • 1
    Just for clarification to future readers: virt-manager is the 'normal' GUI application to manage KVM stuff -- found under Applications > System Tools > Virtual Machine Manager. You may not be able to create a new virtual machine with a new disk on the new pool, but (and BostonDriver, you may want to edit this in) you can create a new volume on the pool, name it whatever, give it a size, and allocate it to your liking, giving it the 'raw' format. Then simply select it as a 'already managed disk' when you're creating the VM. Jul 11 '13 at 15:18

The process of moving VM's in KVM to another disk takes several steps. The first thing you need to do is setup a new storage pool on your second disk. This can be accomplished in virsh or virt-manager. Do do this in virsh you first need to create a XML file that will be referenced during the creation of the storage pool. Here is a sample XML file that you can modify for your specific system.

 <pool type='disk'>
       <device path='/dev/sdb'/>
         <format type='gpt'/>

Once you have created your XML file use virsh pool-define /dir/to/newpool.xml to create the KVM storage pool.

Next use virsh pool-start command to intialize the new pool you just created. You can verify that it was created succesfully by using virsh pool-list --all. You should get something like:

# virsh pool-list --all
Name                 State      Autostart 
default              active     yes       
newpool              active     no

The last thing you need to do is turn on autostart for the new pool using the virsh pool-autostart newpool. This configures the libvirtd service to autostart the disk when the service starts up. You can run virsh pool-list --all again and you should now see that it says yes under the Autostart column. The last thing you can do is check that KVM is reporting the correct size and other info of the new storage pool. This info can be found using this command virsh pool-info newpool.

Once the new pool is created you can start creating VM's on a different disk. Hope that answers your question.

  • If only I could accept two answers! I saw the virt-manager one first, printed it off and ran with it to great success, but this would (or should) work too. Thanks! Jul 11 '13 at 15:15
  • No problem. However it is always nice to be able to do things from the command line and no what is going on behind the scenes.
    – Mike Stock
    Jul 11 '13 at 15:24
  • Agreed, but I wouldn't call such a clean solution 'behind the scenes' ;-) You definitely have more explicit control with command line options (and text-based solutions in general) and I am normally a huge fan, but in this case the graphical workflow is just as expository as the CLI. Jul 11 '13 at 15:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.