Tag: crunchbang

Posted on
by

I recently upgraded my laptop hard drive and decided to move all the virtual disk files of my virtual machines to my home directory.

However, when trying to run the VM, an error notification appeared:

Error starting domain: internal error process exited while connecting to monitor: Warning: option deprecated, use lost_tick_policy property of kvm-pit instead.
kvm: -drive file=/home/sd/libvirt/images/WinXPsp3IE8-d3.qcow2,if=none,id=drive-ide0-0-0,format=raw,cache=writeback: could not open disk image /home/sd/libvirt/images/WinXPsp3IE8-d3.qcow2: Permission denied

The Details section of that dialog showed me where the error was occurring:

Traceback (most recent call last):
 File "/usr/share/virt-manager/virtManager/asyncjob.py", line 45, in cb_wrapper
 callback(asyncjob, *args, **kwargs)
 File "/usr/share/virt-manager/virtManager/asyncjob.py", line 66, in tmpcb
 callback(*args, **kwargs)
 File "/usr/share/virt-manager/virtManager/domain.py", line 1114, in startup
 self._backend.create()
 File "/usr/lib/python2.7/dist-packages/libvirt.py", line 620, in create
 if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error process exited while connecting to monitor: Warning: option deprecated, use lost_tick_policy property of kvm-pit instead.
kvm: -drive file=/home/sd/libvirt/images/WinXPsp3IE8-d3.qcow2,if=none,id=drive-ide0-0-0,format=raw,cache=writeback: could not open disk image /home/sd/libvirt/images/WinXPsp3IE8-d3.qcow2: Permission denied

 

… or, at least, that’s what I hoped.  Except it didn’t.

For a long time, I played around with permissions on the virtual disk image itself, the directory containing it, and further back/up until reaching ~.  None of it helped.

Then I stumbled upon this libvirt bug report.  Comment #6 by Cole Robinson was what I needed:

“What virt-manager typically offers to do is use ACLs to allow the ‘qemu’ user search permissions on your home dir, which is all it should need and is fairly safe and restrictive.”

In order to check and set this, you’ll need to use the File Access Control utilities – getfacl and setfacl:

# cd /home

My home is “sd”

# getfacl sd

# file: sd
# owner: sd
# group: sd
user::rwx
user:root:--x
user:www-data:r-x
group::r-x
group:www-data:r-x
mask::r-x
other::---

The reason I have www-data with read and execute permissions is that I do web development and testing, and I also keep all my web-dev files in ~ too.  This just makes my system more “portable”, safer to upgrade and/or easier to migrate to a different Linux.

To set the required permission for libvirt / qemu, you just issue this one liner:

# setfacl -m u:libvirt-qemu:r-x sd

.. substituting sd for your own ~ directory name.

setfacl (set file access control) takes three main arguments:

  • the action – in this case, -m means “modify” the ACL;
  • the data to apply, colon-separated: here we specify it’s a user (u) who is libvirt-qemu, and the permissions we want to allow are read and execute (r-x).
  • finally, we specify which files or folders ACL should be modified – in this case, my home (sd).

After this, my virtual machine runs up perfectly.

This is relevant for Crunchbang and other Debian-related distros.  For Fedora/CentOS, I believe the user should be qemu.

Posted on
by

When installing Debian, or a derivative OS such as crunchbang, you may have opted to separate out your partitions/logical volumes to manage your disk space more finely.

I opted to do this.  My partitions were set up thus:

$ sudo lvs 

 LV     VG   Attr     LSize   
 home   t420 -wi-ao-- 438.10g 
 root   t420 -wi-ao-- 332.00m 
 swap_1 t420 -wi-ao-- 15.50g     <-- way too big!
 tmp    t420 -wi-ao-- 369.00m    <-- way too small!
 usr    t420 -wi-ao-- 8.38g 
 var    t420 -wi-ao-- 2.79g

This was not working for me.  Doing backups using the easy backintime was proving difficult, as backintime relied on more /tmp space than I had.

As I rarely touched swap space, I figured that 15.5G was probably a bit large for my needs.  Thankfully, nabbing swap space and reusing it for the filesystem is easy as pie – and all achieved with no downtime.

Here’s the sequence I typed into a terminal.  First, turn off swap:

$ sudo swapoff -a

Then resize the swap volume:

$ sudo lvresize -L 8GB /dev/t420/swap_1

Now re-format the swap partition before using it again:

$ sudo mkswap /dev/t420/swap_1

Then turn swap availability back on:

$ sudo swapon -a

And finally, resize the /tmp partition on-the-fly:

$ sudo lvextend -L +1G -r -v /dev/t420/tmp

Because the LVM tools have semi-awareness with respect to filesystems, the resizing of /tmp (using the -r switch) was achieved on-line – no need to log out, reboot or anything else.  The verbose (-v) switch allowed me to see everything that was happening.

The new partition sizing is:

 LV     VG   Attr     LSize 
 home   t420 -wi-ao-- 438.10g 
 root   t420 -wi-ao-- 332.00m 
 swap_1 t420 -wi-ao-- 8.00g 
 tmp    t420 -wi-ao-- 1.37g 
 usr    t420 -wi-ao-- 8.38g 
 var    t420 -wi-ao-- 2.79g

I also have 6.5G spare on the hard drive now, in case it’s needed by another logical volume.

LVM rocks for easy filesystem management!  Try it out!