Volume file permissions and huge volume downloads

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all:

I am using the libvirt version that comes with Ubuntu 18.04.3 LTS.

I want to backup a virtual machine in a foolproof way:

- Gracefully shutdown the VM.
- Backup the disk image.
- Restart the VM.

I wrote the following script to do that:

https://github.com/rdiez/Tools/blob/master/VirtualMachineManager/BackupVm.sh

Writing that script was difficult enough because of the virsh limitations (in my opinion) described in the comments. But at least it works.

The main problem is that libvirt sets the ownership and permissions of volume files in such a way that a standard user cannot access them, even if it is member of the 'libvirt' group.

While the VM is running, volume file permissions are like this:
  -rw-r----- 1 libvirt-qemu kvm [...] /var/lib/libvirt/images/YourVmDisk.qcow2
When the VM is shutoff:
  -rw-r----- 1 root root [...] /var/lib/libvirt/images/YourVmDisk.qcow2

The trouble is, I want to access that .qcow2 file when the VM is shutoff.

I would really like not to run my script as root. I could not find a way to specify the permissions for the .qcow2 files, so I tried editing the group ownership for the whole pool:

virsh pool-edit default

<target>
  <path>/var/lib/libvirt/images</path>
  <permissions>
    <mode>0711</mode>
    <owner>0</owner>
    <group>131</group>
  </permissions>
</target>

Setting <group> to "libvirt" did not work (XML validation error), so I tried the numeric ID of that group (131).

That did not work. When I restart libvirt with "service libvirtd restart", my changes to the pool XML file disappear (!).


Later on, I found out that you can download a volume like this:

  virsh  vol-download  --pool default  YourVmDisk.qcow2  YourVmDisk.qcow2

The trouble is that I created the virtual disk with a maximum size of 120 GB. I copied it around a few times, so I think it has lost any "sparseness" inside. Command "virsh vol-download" takes ages and downloads all those 120 GB. My script uses "qemu-img convert", which discards all unused space and writes just 17 GB of data, and that is without turning compression on. The whole backup takes seconds instead of minutes.


Can somebody help me with these issues?

Thanks in advance,
  rdiez






[Index of Archives]     [Virt Tools]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux