mirror of
https://github.com/libvirt/libvirt.git
synced 2026-10-02 12:20:06 -05:00
John Ferlan
f1856eb622
Commit id 'ac9a0963' refactored out the 'withCapacity' for the virStorageBackendUpdateVolInfo() API. See: http://www.redhat.com/archives/libvir-list/2014-April/msg00043.html This resulted in a difference in how 'virsh vol-info --pool <poolName> <volume>' or 'virsh vol-list vol-list --pool <poolName> --details' outputs the capacity information for a directory pool with a qcow2 sparse file. For example, using the following XML mkdir /home/TestPool cat testpool.xml <pool type='dir'> <name>TestPool</name> <uuid>6bf80895-10b6-75a6-6059-89fdea2aefb7</uuid> <source> </source> <target> <path>/home/TestPool</path> <permissions> <mode>0755</mode> <owner>0</owner> <group>0</group> </permissions> </target> </pool> virsh pool-create testpool.xml virsh vol-create-as --pool TestPool temp_vol_1 \ --capacity 1048576 --allocation 1048576 --format qcow2 virsh vol-info --pool TestPool temp_vol_1 Results in listing a Capacity value. Prior to the commit, the value would be '1.0 MiB' (1048576 bytes). However, after the commit the output would be (for example) '192.50 KiB', which for my system was the size of the volume in my file system (eg 'ls -l TestPool/temp_vol_1' results in '197120' bytes or 192.50 KiB). While perhaps technically correct, it's not necessarily what the user expected (certainly virt-test didn't expect it). This patch restores the code to not update the target capacity for this path
LibVirt : simple API for virtualization
Libvirt is a C toolkit to interact with the virtualization capabilities
of recent versions of Linux (and other OSes). It is free software
available under the GNU Lesser General Public License. Virtualization of
the Linux Operating System means the ability to run multiple instances of
Operating Systems concurrently on a single hardware system where the basic
resources are driven by a Linux instance. The library aim at providing
long term stable C API initially for the Xen paravirtualization but
should be able to integrate other virtualization mechanisms if needed.
Daniel Veillard <veillard@redhat.com>