Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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?

share|improve this question

2 Answers 2

up vote 1 down vote accepted

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.

share|improve this answer
    
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. –  Sean Allred 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'>
   <name>newpool</name>
     <source>
       <device path='/dev/sdb'/>
         <format type='gpt'/>
     </source>
   <target>
     <path>/dev</path>
   </target>
 </pool>

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.

share|improve this answer
    
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! –  Sean Allred 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. –  mikeastock 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. –  Sean Allred Jul 11 '13 at 15:31

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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