[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1025244
Title:
qcow2 image
[Expired for qemu-kvm (Ubuntu) because there has been no activity for 60
days.]
** Changed in: qemu-kvm (Ubuntu)
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1025
Looking through old bug tickets... is there anything left to do here? Or
should we rather close this ticket nowadays?
** Changed in: qemu
Status: New => Incomplete
** Changed in: qemu-kvm (Ubuntu)
Status: Triaged => Incomplete
--
You received this bug notification because you are
@Mario,
the external snapshots have apparently been around a long time. The
ability to create external snapshots from running vms is newer, but
it appears to exist evn in qemu-kvm 1.0. So all versions in Debian
and Ubuntu should support them.
http://wiki.qemu.org/Features/Snapshots#Snapshot_com
@serge, what version would I need to upgrade to be able to use the
external snapshots? that sounds like it would solve my problems
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1025244
Title:
qcow2
@Mario, in theory an image "that should be taking up 30 GB" with four
snapshots should be taking up at most about 150 GB, of course. Now the
question is what you mean by "should be taking up 30 GB" and by "is
taking 600+ GB".
For the latter, did you query the file length (ls -l) or the actual size
For the record, the workaround is deleting old snapshots in shutdown mode
as per comment #14.
Upstream has moved toward external snapshots as the way forward, so while
I don't argue that this is a bug, it seems unlikely to receive a fix from
upstream.
--
You received this bug notification becaus
@michael, so you do that once, after some time the machine keeps
growing, and growing and growing... and you have to redo that every so
often... I have a machine that should be taking up 30 gb yet is taking
600+ GB with 4 snapshots... but yeah... I'll just plug in another 1tb
hard drive so that i
Changing priority given workarounds.
** Changed in: qemu-kvm (Ubuntu)
Importance: High => Low
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1025244
Title:
qcow2 image increasing disk size above
Looking at what? At the lack of problems as comment #14 says?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1025244
Title:
qcow2 image increasing disk size above the virtual limit
To manage notifi
Is anyone even looking at this? been years and the problem still
persists!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1025244
Title:
qcow2 image increasing disk size above the virtual limit
To m
Thanks for your advices. I have no more problems with VM-size since
deleting snapshot in shutdown-mode. I reduced the overlarge qcow2-images
by converting in qcow2 again (that detects unused sectors and omits
this).
--
You received this bug notification because you are a member of Ubuntu
Bugs, wh
On 01/02/2013 08:50 AM, Stefan Hajnoczi wrote:
> On Tue, Dec 18, 2012 at 10:18:20AM -, Andy Menzel wrote:
>> Any solution right now? I have a similar problem like Todor Andreev;
>> Our daily backup of some virtual machines (qcow2) looks like that:
>>
>> 1. shutdown the VM
>> 2. create a snapsho
On Tue, Dec 18, 2012 at 10:18:20AM -, Andy Menzel wrote:
> Any solution right now? I have a similar problem like Todor Andreev;
> Our daily backup of some virtual machines (qcow2) looks like that:
>
> 1. shutdown the VM
> 2. create a snapshot via: "qemu-img snapshot -c nameofsnapshot..."
> 3.
I don't know of any qcow2-based workaround.
Is anyone actively working on fixing the qcow2 code? In particular, the
fact that after removing snapshots, un-used blocks are not reclaimed and
disk size is never reduced?
One possible workaround (the one I would use) would be to use lvm-based
snapsho
Any solution right now? I have a similar problem like Todor Andreev;
Our daily backup of some virtual machines (qcow2) looks like that:
1. shutdown the VM
2. create a snapshot via: "qemu-img snapshot -c nameofsnapshot..."
3. boot the VM
4. backup the snapshot to another virtual disk via: "qemu-img
@Todor,
Thanks, you might be right. It sounds like it's not a missing feature
but a bug. I'll re-raise the priority.
** Also affects: qemu
Importance: Undecided
Status: New
** Changed in: qemu-kvm (Ubuntu)
Importance: Low => High
--
You received this bug notification because you
I'm sorry, I meant 21. not 20.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1025244
Title:
qcow2 image increasing disk size above the virtual limit
To manage notifications about this bug go to:
ht
@Serge, thank you for answering.
Well, I think this is not entirely true. I think that from my above post, 13.
and 20. should be with the same results, if it were true. The truth is that
when a snapshot is present, sometimes it uses the available space, sometimes it
doesn't. (!???)
I think there
I did some testing with a WindowsXP guest, that I have and could test on.
It seems that this behavior is not present at the beginning. But at the moment
we create a snapshot it is starting to write on top of the current size. So, it
is like this:
1. Image is:
Code:
qemu-img info WindowsXP.img
May be here will be more convenient for reading:
http://www.linuxquestions.org/questions/linux-virtualization-90/disk-physical-size-more-than-virtual-size-qcow2-image-4175416848/#post4730524
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubun
First going back to the original bug, in that instance you kept around
many snapshots. In that case there is no way to avoid having many
snapshots of, say, a 2G disk, taking much more space than 2G.
The thing that concerned me in this bug was that disk space was never
reclaimed.
I don't believe
Yes, I have created one snapshot and did fallocate in the beginning. The
other image, which I have problems with, also has snapshots.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1025244
Title:
qco
I started playing with this by just doing:
qemu-img create -f qcow2 x.img 2G
(boot a vm from a cdrom/iso into rescue mode with x.img as a drive, and there
do):
dd if=/dev/zero of=/mnt/zero1 bs=1M count=1000
and then
cp /mnt/zero1 /mnt/zero2
rm /mnt/zero2
cp /mnt/zero1 /mnt/zero3
(et
Thanks for filing this bug, Todor. I'll try figure out whether this is
still the case in the upstream git HEAD.
** Changed in: libvirt (Ubuntu)
Status: New => Confirmed
** Changed in: libvirt (Ubuntu)
Importance: Undecided => High
** Package changed: libvirt (Ubuntu) => qemu-kvm (Ubun
25 matches
Mail list logo
