[Qemu-devel] QCOW image corruption under QEMU 0.9.0

[Qemu-devel] QCOW image corruption under QEMU 0.9.0

[J M Cerqueira Esteves]

Greetings

I got some error messages shortly after booting a Debian guest under
QEMU 0.9.0.  I did not annotate those, but they made me believe there
could be disk access problems, and if fact something weird happened to
one of the disk images (this was using two images, for hda and hdb):

After shutting down the guest, I inspected its image files with
qemu-info, which reported for hda

image: nisaba.hda.qcow
file format: raw
virtual size: 4.3G (4596273152 bytes)
disk size: 4.3G

but hda was supposed to have a virtual size of approximately 20 GB,
QCOW2 format and a saved snapshot...

The hdb image still seems OK:

image: nisaba.hdb.qcow
file format: qcow2
virtual size: 2.0G (2147483648 bytes)
disk size: 216M
cluster_size: 4096
Snapshot list:
ID        TAG                 VM SIZE                DATE       VM CLOCK
1         20070217                66M 2007-02-17 05:58:40   46:06:17.193

I'll keep a copy of the damaged image in case someone competent on qemu
and qcow wishes to inspect it, but in case this may be suggestive:
I noticed that the only non-zero bytes until byte 12288 (where a first
'more random' sequence starts) are:
  byte 4102: 0x20
       4110: 0x30
       4118: 0x40
       ... and so on, until
       4206: 0xf0
       4221-4222: 0x0110
       4229-4230: 0x0120
       4237-4238: 0x0130
       4245-4246: 0x0140
       4252-4254: 0xd547b0
       4260-4262: 0xd547c0
        ...
       8180-8182: 0xd56660
       8188-8190: 0xd56670
       11776-11791: 0x6c6f3d 6c6f0a 6574 68303d 6574 68300a

Unvortunately I don't have an older copy of the hda image
with which to compare this broken one.  In any case
I have been running, in the same host, several 32-bit guests with Debian
and one with Windows XP, almost without any problems, first under QEMU
0.8.2 and since February 11 under QEMU 0.9.0 (with some images then
migrated from QCOW to QCOW2).

Details on the configuration:

Host: AMD Athlon 64 3500+ (HP dx5150 MT)
      with Ubuntu 6.06 LTS, kernel 2.6.15-28-amd64-k8.
VDE: 'backported' (just rebuilding the package)
     from Debian testing's vde 1.5.11-1.
QEMU: 0.9.0, configured with --cc=gcc-3.4 --enable-alsa
kqemu: 1.3.0pre11

Guest: Debian Etch (32-bit), with kernel 2.6.18-k7 (if I remember
       correctly);
       / was on hda, the failed image file;
       /tmp and swap on hdb, the surviving image.

QEMU was invoked with
vdeq qemu-system-x86_64 \
        -kernel-kqemu \
        -pidfile nisaba.pid \
        -m 192 \
        -std-vga \
        -net nic,vlan=0,model=rtl8139,macaddr=4A:4D:23:00:00:01 \
        -net vde,vlan=0,sock=/var/run/vde/tap-vde-1.ctl \
        -hda nisaba.hda.qcow -hdb nisaba.hdb.qcow

Best regards
                                  J Esteves

[Qemu-devel] Re: QCOW image corruption under QEMU 0.9.0

[J M Cerqueira Esteves]

J M Cerqueira Esteves wrote:
>        11776-11791: 0x6c6f3d 6c6f0a 6574 68303d 6574 68300a

                   6c6f 3d 6c6f 0a
                   65746830 3d 65746830 0a

or, of course (duh, I should have noticed, although I'm not sure this
can help),
                   lo=lo\n
                   eth0=eth0\n

[Qemu-devel] MORE QCOW image corruption under QEMU 0.9.0

[AN support]

J M Cerqueira Esteves wrote:
> After shutting down the guest, I inspected its image files with
> qemu-info, which reported for hda
> 
> image: nisaba.hda.qcow
> file format: raw
> virtual size: 4.3G (4596273152 bytes)
> disk size: 4.3G
> 
> but hda was supposed to have a virtual size of approximately 20 GB,
> QCOW2 format and a saved snapshot...

And now I got another corrupted image:

This time, after installing some packages in a similar Debian guest,
the system froze while shutting down (using 100% CPU on host).
I then noticed that its supposed QCOW2 image file (a 20 GB virtual disk,
in a by then more than 4GB file) was no longer considered to be a QCOW2
image, as above.

Curiously this damaged image file has 4543348736 bytes.
I wonder if there some new bug triggered by the image file size,
for some size around 4500000000 bytes...

Fortunately this time I have a backup copy of the virtual disk state
just before it was corrupted.  I'll try to see what happens if I convert
it from qcow2 to qcow before proceeding.  Any more suggestions?

Best regards
                               J Esteves

Re: [Qemu-devel] QCOW image corruption under QEMU 0.9.0

[J M Cerqueira Esteves]

J M Cerqueira Esteves wrote:
> After shutting down the guest, I inspected its image files with
> qemu-info, which reported for hda
>
> image: nisaba.hda.qcow
> file format: raw
> virtual size: 4.3G (4596273152 bytes)
> disk size: 4.3G
>
> but hda was supposed to have a virtual size of approximately 20 GB,
> QCOW2 format and a saved snapshot...

And now I got another corrupted image:

This time, after installing some packages in a similar Debian guest,
the system froze while shutting down (using 100% CPU on host).
I then noticed that its supposed QCOW2 image file (a 20 GB virtual disk,
in a by then more than 4GB file) was no longer considered to be a QCOW2
image, as above.

Curiously this damaged image file has 4543348736 bytes.
I wonder if there some new bug triggered by the image file size,
for some size around 4500000000 bytes...

Fortunately this time I have a backup copy of the virtual disk state
just before it was corrupted.  I'll try to see what happens if I convert
it from qcow2 to qcow before proceeding.  Any suggestions?

Best regards
                               J Esteves

Re: [Qemu-devel] QCOW image corruption under QEMU 0.9.0

[J M Cerqueira Esteves]

J M Cerqueira Esteves wrote:
> Curiously this damaged image file has 4543348736 bytes.
> I wonder if there some new bug triggered by the image file size,
> for some size around 4500000000 bytes...

I have a copy of the disk image file as it was just before starting the
qemu run which damaged it, and now I noticed that, during that qemu run,
the image file size did not change: 4543348736 bytes.

However, comparing both images with  cmp -l  shows extensive changes.
Just an example, from the first bytes (byte number, original value,
corrupted value):

         1 121   0
         2 106   0
         3 111   0
         4 373   0
         8   2   0
        24  14   0
        28   5   0
        39  50   0
        47  20   0
        52   1   0
        55  20   0
        60   2   0
      1881   0 200
      1887   0  40
      1889   0 200
      1895   0 100
      9049 200   0
      9054   1   0
      9055 220   0
      9057 200   0
      9061  60   0
      9062 115   0
      9063 100   0
... many more zeroed out...
     49487 220   0
     49569 200   0
     49573 325   0
     49574 357   0
     49575 300   0
     49665   0 147
     49666   0 145
     49667   0  55
     49668   0  62
     49669   0  56
     49670   0  66
     49671   0  56
     49672   0  61
     49673   0  70
     49674   0  55
     49675   0  63
     49676   0  55
     49677   0 153
 ... many more un-zeroed ...
     49853   0  40
     49854   0 151
     49855   0 163
     49856   0  40
     49857 200 141
     49858   0 166
     49859   0 141
     49860   0 151
     49861  46 154
     49862 174 141
     49863 140 142
     49864   0 154
     49865   0 145
 ... many more un-zeroed ...
     49983   0 142
     49984   0 157
     49985 200 157
     49986   0 164
     49987   0  40
     49988   0 171
     49989  15 157
     49990 354 165
     49991 200 162
     49992   0  40
     49993 200 155
     49994   0 141
     49995   0 143
     49996   0 150
     49997  16 151
     49998   1 156
     49999 260 145
     50000   0  56
     50001   0  12
     50002   0  12
    ...

Best regards
                                                     J Esteves

Re: [Qemu-devel] QCOW image corruption under QEMU 0.9.0

[J M Cerqueira Esteves]

J M Cerqueira Esteves wrote:
> This time, after installing some packages in a similar Debian guest,
> the [guest] system froze while shutting down (using 100% CPU on host).
> I then noticed that its supposed QCOW2 image file (a 20 GB virtual disk,
> in a by then more than 4GB file) was no longer considered to be a QCOW2
> image, as above.
> 
> Curiously this damaged image file has 4543348736 bytes.
> I wonder if there some new bug triggered by the image file size,
> for some size around 4500000000 bytes...

I took a copy of that qcow2 image file (made just before the 'fatal'
qemu session), converted it to qcow, restarted qemu using this qcow
version, reinstalled the additional Debian packages I had installed
during the corrupting session (and more), even rebooted with a Debian
pre-built 2.6.18 k7 kernel (the previous one there was the '686' variant).

The resulting image file now has 4555382784 bytes (a bit larger than the
previously damaged image) and it is still recognized as a qcow image.

It seems there is some qcow2-specifig bug...

Best regards
                        J Esteves

[Qemu-devel] QEMU with smp

[Danny Chieh-Yao, Cheng]

Hi all,

I am trying to run QEMU under Windows, but I can't get -smp 2 working. I 
know that QEMU under Windows is still alpha stage, but does anyone know 
if the -smp 2 option works at all under Windows? I am getting the error 
"Can't find cpu1" and QEMU just halts.

Thanks,
Danny

[Qemu-devel] Qemu with smp

[Girish V]

Hi,
I am trying to install FC5 SMP kernel on a disk image. My plan is to
boot up a qemu smp machine and install FC5 - this way the installer
will detect the 2 cpus and install the smp kernel.

I tried to boot up a machine with 2 cpus, using "qemu -m 512M -hda
disc.img -smp 2 -cdrom FC5-disc1.iso -no-kqemu -boot d". When I do
this, a blank console pops up - but nothing happens beyond that. The
console is blank and the installation doesnt seem to progress.

If I try the above command without the -smp 2 option, I am able to see
the welcome screen and installation progresses.

Is there something else I need to do so that I can use the smp option.
I am running qemu on Ubuntu Hardy Heron

Thanks,
Girish