[libvirt-users] virt-sparsify changing the apparent-size of files
libvirt_users at skagitattic.com
libvirt_users at skagitattic.com
Wed Jun 22 22:56:09 UTC 2016
> Delete what you've done and start from the beginning. Describe
> exactly how you created the guest. Use 'qemu-img info' to show the
> format of the input file. Show precisely the virt-sparsify command
> you are running. And use 'qemu-img info' on the output file too.
Okay, here goes. Start off with an install
root at testingbox:~ # virt-install --name testimage --memory 512 -l
'http://ftp.nl.debian.org/debian/dists/jessie/main/installer-amd64/'
--disk size=50 --nographics -x "console=ttyS0"
Starting install...
Retrieving file
MANIFEST...
| 3.3 kB 00:00 ... Retrieving file
linux...
| 6.0 MB 00:03 ... Retrieving file
initrd.gz...
| 29 MB 00:09 ... Allocating
'testimage.qcow2'
| 50 GB 00:00 Creating
domain...
| 0 B 00:00 Connected to domain testimage Escape character is
[ 0.000000] Initializing cgroup subsys cpuset [ 0.000000]
Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup
subsys cpuacct [ 0.000000] Linux version 3.16.0-4-amd64
(debian-kernel at lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1)
) #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08)
.... Many more lines here and it turns interactive. Suffice it to
say I did a basic minimal install following the prompts. Nothing
special here.
This created an image that is 2.5G with a 50G apparent size and
identifies as qcow2 as shown below.
# ls -slh testimage.qcow2
2.5G -rw-r--r-- 1 root root 51G Jun 22 20:22 testimage.qcow2
# qemu-img info testimage.qcow2
image: testimage.qcow2
file format: qcow2
virtual size: 50G (53687091200 bytes)
disk size: 2.4G
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: true
Now we sparsify (/bigtmp is on a larger partition then / to give
virt-sparsify enough room to work with so it does not complain).
root at testingbox: 08:59 PM # virt-sparsify testimage.qcow2
testimage1.qcow2 --tmp /bigtmp Input disk virtual size = 53687091200
bytes (50.0G) Create overlay file in /bigtmp to protect source
disk ... Examine source disk ...
100%
⟦▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒⟧
--:-- Fill free space in /dev/sda1 with zero ... 100%
⟦▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒⟧
00:00 Clearing Linux swap on /dev/sda5 ... 100%
⟦▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒⟧
--:-- Copy to destination and make sparse ...
Sparsify operation completed with no errors. Before deleting the
old disk, carefully check that the target disk boots and works
correctly.
root at testingbox: 09:04 PM #
This image reports still reports as qcow2 however the apparent and real
size is the same.
# ls -slh testimage1.qcow2
1.1G -rw-r--r-- 1 root root 1.1G Jun 22 21:04 testimage1.qcow2
# qemu-img info testimage1.qcow2
image: testimage1.qcow2
file format: qcow2
virtual size: 50G (53687091200 bytes)
disk size: 1.1G
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: false
If we try it again but specify raw its MUCH faster
root at testingbox: 09:26 PM # virt-sparsify testimage.qcow2
testimage2.qcow2 --tmp /bigtmp --format raw Input disk virtual size
= 53687091200 bytes (50.0G) Create overlay file in /bigtmp to
protect source disk ... Examine source disk ...
Copy to destination and make sparse ...
Sparsify operation completed with no errors. Before deleting the
old disk, carefully check that the target disk boots and works
correctly.
root at testingbox: 09:27 PM #
This time it takes up more space and reports real and apparent size
differently. It still reports as qcow2 with qemu-img.
# ls -slh testimage2.qcow2
1.7G -rw-r--r-- 1 root root 51G Jun 22 21:27 testimage2.qcow2
# qemu-img info testimage2.qcow2
image: testimage2.qcow2
file format: qcow2
virtual size: 50G (53687091200 bytes)
disk size: 1.7G
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: true
The only things I see different from the finished files is that the raw
one uses a bit more space, the apparent size is not set to the
virtual size on the default sparsify one and the lazy refcounts is
different.
Is there something more detailed then "qemu-img info" that I could tell
the difference with?
> Raw has fewer features, especially no simple snapshotting or support
> for backing files.
Is simple snapshotting using qemu-img snapshot or something else? I
tried making a snapshot with both test images and they both appeared to
work.
# qemu-img snapshot -c test testimage1.qcow2
# qemu-img snapshot -c test testimage2.qcow2
# qemu-img info testimage2.qcow2
image: testimage2.qcow2
file format: qcow2
virtual size: 50G (53687091200 bytes)
disk size: 1.7G
cluster_size: 65536
Snapshot list:
ID TAG VM SIZE DATE VM
CLOCK 1 test 0 2016-06-22 22:41:52
00:00:00.000 Format specific information:
compat: 1.1
lazy refcounts: true
# qemu-img info testimage1.qcow2
image: testimage1.qcow2
file format: qcow2
virtual size: 50G (53687091200 bytes)
disk size: 1.1G
cluster_size: 65536
Snapshot list:
ID TAG VM SIZE DATE VM
CLOCK 1 test 0 2016-06-22 22:41:44
00:00:00.000 Format specific information:
compat: 1.1
lazy refcounts: false
The backing file thing appeared to work on the 2nd one where I
specified raw as well.
# qemu-img create -f qcow2 -b testimage2.qcow2 backup-test2.qcow2
Formatting 'backup-test2.qcow2', fmt=qcow2 size=53687091200
backing_file='testimage2.qcow2' encryption=off cluster_size=65536
lazy_refcounts=off
# ls -lsh
backup-test2.qcow2 196K -rw-r--r-- 1 root root 193K Jun 22 22:48
backup-test2.qcow2
Though perhaps if I actually tried to add them and boot it up something
would not work?
Keelan
On Wed, 22 Jun 2016 09:58:29 +0100
"Richard W.M. Jones" <rjones at redhat.com> wrote:
> On Wed, Jun 22, 2016 at 12:40:40AM -0500,
> libvirt_users at skagitattic.com wrote:
> > So you are saying when I do the virt-sparsify its converting the
> > image from raw to [qcow2]?
>
> No. virt-sparsify will use the same input and output formats, unless
> you use the --convert option.
>
> > I studied the man page for virt-sparsify and tried again with
> > the flag "--format raw" (output2.cow2). This output files looks as
> > I first expected.
> >
> > # ls -lrh
> > total 4.7G
> > -rw-r--r-- 1 root root 790M Jun 14 22:36 output.qcow2
> > -rw-r--r-- 1 root root 51G Jun 21 18:34 output2.qcow2
> > -rw-r--r-- 1 root root 51G Jun 14 22:30 input.qcow2
> > -rw-r--r-- 1 root root 512M Jun 14 22:30 file.img
> > # du -sh *
> > 0 file.img
> > 2.4G input.qcow2
> > 1.6G output2.qcow2
> > 790M output.qcow2
> >
> > So I guess it was detecting the source wrong and doing a conversion?
> > (As it says "If this is not specified, then the input format is
> > used." in the man page)
> >
> > Also seems odd that it is 1.6G rather then the 790M of the output in
> > qcow2 format. Does qcow2 do some compression or something?
>
> I'm really confused about what you actually are doing.
>
> Delete what you've done and start from the beginning. Describe
> exactly how you created the guest. Use 'qemu-img info' to show the
> format of the input file. Show precisely the virt-sparsify command
> you are running. And use 'qemu-img info' on the output file too.
>
> > Is there any reason to use raw vs non-raw? From some reading
> > online it appears performance is better with raw files. Is there a
> > downside to using raw?
>
> Raw has fewer features, especially no simple snapshotting or support
> for backing files.
>
> Rich.
>
More information about the libvirt-users
mailing list