Hot answers tagged qcow2
7
The image will not shrink automatically, since when you delete files, you don't actually delete data (this is why undelete works). Qemu has a facility to shrink qcow2 images back, but what the utility does is really deduplicate the zeroes from the disk, leaving all other information intact. So the idea would be to:
Zero-fill the drive (dd if=/dev/zero ...
6
This issue was caused by the way libvirt uses apparmor.
The default behavior is to provide some protection for the host against the guest by restricting which files the virtualization process on the host is allowed to access. libvirt knows that the virtualization process (kvm in this case) needs the disk image in order to operate properly, so it creates an ...
4
You'll want to coordinate that within the guest .. ideally you:
Cause any RDBMS running in the guest to flush its cache
Tell Linux to sync disks (sysrq S or just type 'sync')
Then just make a qcow2 snapshot of the guest. You then have a read-only immutable copy of the guest FS as it was when you took the snapshot.
This page offers a lot more information ...
3
Well, LVM images inside qcow2 files is a mess. I personally try to avoid them, as multiple layers of LVM can cause shocking headaches.
But you will find the answer here:
Mount LVM within a disk image.
Good luck!
2
Yes, you do need to zero-fill the filesystem if you want to recover the space used by deleted files. And no, qemu-img isn't fs-aware.
I forgot to do this for one VM image I created today (a minimal Debian Sid image for my openstack cloud at work) and it ended up being almost 900MB, even with "-c" for qcow2 compression.
I recreated it after running "dd ...
2
Assuming you have already transferred the images themselves and configured added their definitions to the destination libvirt instance all you need to do is to transfer the snapshot definitions as well. Here's a little script to aid you:
#!/bin/sh
SRC_URL=qemu:///system
SRC_DOMAIN_NAME=test
SRC_DOMAIN_UUID=`virsh -c $SRC_URL domuuid $SRC_DOMAIN_NAME`
...
2
A bug related to this was fixed in qemu version 1.2.0. Ubuntu 12.04 has an older qemu version, but if you install qemu-img from source code
user@ubuntu:/tmp$ sudo apt-get install libglib2.0-dev
user@ubuntu:/tmp$ wget http://wiki.qemu.org/download/qemu-1.2.0.tar.bz2
user@ubuntu:/tmp$ tar xfj qemu-1.2.0.tar.bz2
user@ubuntu:/tmp$ cd qemu-1.2.0
...
1
Very easy - create and define a new VM with virsh edit, virt-manager or virt-install, and instead of creating the new disk images, attach the existing ones. You will need to move the images into libvirt's image store, or define an image store where the existing images are kept.
1
You should apply the snapshot and mount the image like always. It's better to create a snapshot right before applying if you want to turn back to the original disk contents before you do these operations. After you apply the snapshot you just mount the image with qemu-nbd as always:
# modprobe nbd max_part=8
$ qemu-img snapshot -c backup image.qcow2
$ ...
1
I was looking for similar solution,
now I'm using software RAID+LVM2 volume for libvirt storage, I've taken a snapshot and few times (about 8-10) I had to revert to backup and it worked, even if Win guest said: unclean shutdown.
I'm not using hardware RAID anyway, software is enough but prorably SCSI/SAS + HW RAID + battery backup is the best solution for ...
Only top voted, non community-wiki answers of a minimum length are eligible
