All of lore.kernel.org
 help / color / mirror / Atom feed
From: Max Reitz <max_felix.reitz@mailbox.tu-dresden.de>
To: Paolo Bonzini <pbonzini@redhat.com>,
	"Prof. Dr. Michael Schefczyk" <michael@schefczyk.net>,
	qemu-devel <qemu-devel@nongnu.org>
Cc: Kevin Wolf <kwolf@redhat.com>
Subject: Re: [Qemu-devel] "File too large" error from "qemu-img snapshot" (was Re: AW: Bug Repoting Directions Request)
Date: Wed, 19 Nov 2014 15:05:48 +0100	[thread overview]
Message-ID: <546CA3BC.9060303@mailbox.tu-dresden.de> (raw)
In-Reply-To: <546C8200.4070800@redhat.com>

On 19.11.2014 12:41, Paolo Bonzini wrote:
>
> On 19/11/2014 12:39, Prof. Dr. Michael Schefczyk wrote:
>> Dear Paolo,
>>
>> thank you very much for your prompt reply.
> Hi,
>
> please keep the replies on the mailing list.  I've added the qemu-devel
> mailing list, where more people should be able to see the message and
> hopefully reply with something helpful.
>
> Also, how do you do the backups?
>
> Paolo
>
>> For example, I have a guest named "gatewayb72.img" where the backup failed. If I thereafter try to create or delete a snapshot, the following reply occurs on the command line:
>>
>>
>> [root@linuxhost2 kvm02]# qemu-img snapshot -d gatewayb72 /kvm02/gatewayb72.img
>> qemu-img: Could not open '/kvm02/gatewayb72.img': Could not read snapshots: File too large
>>
>>
>> If I want to reboot that machine, I get the following error:
>>
>>
>> Fehler beim Starten der Domain: Interner Fehler: Prozess wurde während der Verbindungsaufnahme zum Monitor beendet : qemu-kvm: -drive file=/kvm02/gatewayb72.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=none: could not open disk image /kvm02/gatewayb72.img: Could not read snapshots: File too large
>>
>>
>> Traceback (most recent call last):
>>    File "/usr/share/virt-manager/virtManager/asyncjob.py", line 100, in cb_wrapper
>>      callback(asyncjob, *args, **kwargs)
>>    File "/usr/share/virt-manager/virtManager/asyncjob.py", line 122, in tmpcb
>>      callback(*args, **kwargs)
>>    File "/usr/share/virt-manager/virtManager/domain.py", line 1220, in startup
>>      self._backend.create()
>>    File "/usr/lib64/python2.7/site-packages/libvirt.py", line 698, in create
>>      if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
>> libvirtError: Interner Fehler: Prozess wurde während der Verbindungsaufnahme zum Monitor beendet : qemu-kvm: -drive file=/kvm02/gatewayb72.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=none: could not open disk image /kvm02/gatewayb72.img: Could not read snapshots: File too large
>>
>>
>> Based on the facts I can see, the file is not too large. When reading the first error, the file size was 13.8 GB, while the limit is 14.5 GB. The same does also happen with files which are only, for example 6 GB big, while their limit is also 14.5 GB. Therefore, I think that the "file too large" really stands for something else.

It most probably does, yes. Some months ago, we included a limit in 
qemu's qcow2 implementation for the (internal) snapshot table size. When 
this limit is hit, "File too large" will be printed (it's a pretty bad 
error message, I know, but we thought it never to occur for reasonable 
images, so we did not see the need to improve it). That limit is 64 MB, 
which comes from having 1 kB of metadata per snapshot in average and a 
maximum of 64k snapshots. 1 kB per snapshot is reasonable: Normally, you 
have 56 bytes plus the length of the snapshot's name plus the length of 
the snapshot's ID (plus a couple of bytes of padding).

We have indeed seen some bug reports regarding this limit; however, 
nobody could provide us with an image to look into this issue so far (as 
far as I'm aware), and we could not reproduce it ourselves.

I understand that providing a 13.8 GB image is a bit much, but maybe you 
are able to do it anyway (the TU Dresden does have a reasonable internet 
connection, as far as I'm aware) or, if possible, provide us with 
information on how to recreate a similar image ourselves.

Max

      parent reply	other threads:[~2014-11-19 14:06 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-19 10:36 Bug Repoting Directions Request Prof. Dr. Michael Schefczyk
2014-11-19 10:59 ` Paolo Bonzini
     [not found]   ` <2A6E6B95B6E5C146ACE8440760E58185BDC31C30@EXCHANGESERVER.schefczyk.local>
2014-11-19 11:41     ` [Qemu-devel] "File too large" error from "qemu-img snapshot" (was Re: AW: Bug Repoting Directions Request) Paolo Bonzini
2014-11-19 11:48       ` Prof. Dr. Michael Schefczyk
2014-11-19 11:53         ` Paolo Bonzini
2014-11-19 12:07           ` Prof. Dr. Michael Schefczyk
2014-11-19 14:54             ` Paolo Bonzini
2014-11-19 15:43               ` Eric Blake
2014-11-19 17:32                 ` Prof. Dr. Michael Schefczyk
2014-11-19 18:13                   ` Eric Blake
2014-11-22 17:02                     ` Prof. Dr. Michael Schefczyk
2014-11-24 11:52                       ` Paolo Bonzini
2014-11-25 11:34                       ` Kevin Wolf
2014-11-25 11:49                         ` Prof. Dr. Michael Schefczyk
2014-11-24 10:32                     ` Kashyap Chamarthy
2014-11-19 14:05       ` Max Reitz [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=546CA3BC.9060303@mailbox.tu-dresden.de \
    --to=max_felix.reitz@mailbox.tu-dresden.de \
    --cc=kwolf@redhat.com \
    --cc=michael@schefczyk.net \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.