[Qemu-devel] [Bug 1292234] Re: qcow2 image corruption in trusty (qemu 1.7 and 2.0 candidate)

[Qemu-devel] [Bug 1292234] Re: qcow2 image corruption in trusty (qemu 1.7 and 2.0 candidate)

[Chris J Arges]

Also I've been able to reproduce this with the latest master in qemu,
and even with the latest daily 3.18-rcX kernel on the host.

** Also affects: qemu
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1292234

Title:
  qcow2 image corruption in trusty (qemu 1.7 and 2.0 candidate)

Status in QEMU:
  New
Status in qemu package in Ubuntu:
  Confirmed

Bug description:
  The security team uses a tool (http://bazaar.launchpad.net/~ubuntu-
  bugcontrol/ubuntu-qa-tools/master/view/head:/vm-tools/uvt) that uses
  libvirt snapshots quite a bit. I noticed after upgrading to trusty
  some time ago that qemu 1.7 (and the qemu 2.0 in the candidate ppa)
  has had stability problems such that the disk/partition table seems to
  be corrupted after removing a libvirt snapshot and then creating
  another with the same name. I don't have a very simple reproducer, but
  had enough that hallyn suggested I file a bug. First off:

  qemu-kvm 2.0~git-20140307.4c288ac-0ubuntu2

  $ cat /proc/version_signature
  Ubuntu 3.13.0-16.36-generic 3.13.5

  $ qemu-img info ./forhallyn-trusty-amd64.img
  image: ./forhallyn-trusty-amd64.img
  file format: qcow2
  virtual size: 8.0G (8589934592 bytes)
  disk size: 4.0G
  cluster_size: 65536
  Format specific information:
      compat: 0.10

  Steps to reproduce:
  1. create a virtual machine. For a simplified reproducer, I used virt-manager with:
    OS type: Linux
    Version: Ubuntu 14.04
    Memory: 768
    CPUs: 1

    Select managed or existing (Browse, new volume)
      Create a new storage volume:
        qcow2
        Max capacity: 8192
        Allocation: 0

    Advanced:
      NAT
      kvm
      x86_64
      firmware: default

  2. install a VM. I used trusty-desktop-amd64.iso from Jan 23 since it
  seems like I can hit the bug more reliably if I have lots of updates
  in a dist-upgrade. I have seen this with lucid-trusty guests that are
  i386 and amd64. After the install, reboot and then cleanly shutdown

  3. Backup the image file somewhere since steps 1 and 2 take a while :)

  4. Execute the following commands which are based on what our uvt tool
  does:

  $ virsh snapshot-create-as forhallyn-trusty-amd64 pristine "uvt snapshot"
  $ virsh snapshot-current --name forhallyn-trusty-amd64
  pristine
  $ virsh start forhallyn-trusty-amd64
  $ virsh snapshot-list forhallyn-trusty-amd64 # this is showing as shutoff after start, this might be different with qemu 1.5

  in guest:
  sudo apt-get update
  sudo apt-get dist-upgrade
  780 upgraded...
  shutdown -h now

  $ virsh snapshot-delete forhallyn-trusty-amd64 pristine --children
  $ virsh snapshot-create-as forhallyn-trusty-amd64 pristine "uvt snapshot"

  $ virsh start forhallyn-trusty-amd64 # this command works, but there
  is often disk corruption

  The idea behind the above is to create a new VM with a pristine
  snapshot that we could revert later if we wanted. Instead, we boot the
  VM, run apt-get dist-upgrade, cleanly shutdown and then remove the old
  'pristine' snapshot and create a new 'pristine' snapshot. The
  intention is to update the VM and the pristine snapshot so that when
  we boot the next time, we boot from the updated VM and can revert back
  to the updated VM.

  After running 'virsh start' after doing snapshot-delete/snapshot-
  create-as, the disk may be corrupted. This can be seen with grub
  failing to find .mod files, the kernel not booting, init failing, etc.

  This does not seem to be related to the machine type used. Ie, pc-
  i440fx-1.5, pc-i440fx-1.7 and pc-i440fx-2.0 all fail with qemu 2.0,
  pc-i440fx-1.5 and pc-i440fx-1.7 fail with qemu 1.7 and pc-i440fx-1.5
  works fine with qemu 1.5.

  Only workaround I know if is to downgrade qemu to 1.5.0+dfsg-
  3ubuntu5.4 from Ubuntu 13.10.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1292234/+subscriptions

Re: [Qemu-devel] [Bug 1292234] Re: qcow2 image corruption in trusty (qemu 1.7 and 2.0 candidate)

[Serge Hallyn]

Excellent!

Any chance you can start bisecting with
http://people.canonical.com/~serge/binaries.{0..68}/{qemu-img,qemu-
system-x86_64} ?

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1292234

Title:
  qcow2 image corruption in trusty (qemu 1.7 and 2.0 candidate)

Status in QEMU:
  New
Status in qemu package in Ubuntu:
  Confirmed

Bug description:
  The security team uses a tool (http://bazaar.launchpad.net/~ubuntu-
  bugcontrol/ubuntu-qa-tools/master/view/head:/vm-tools/uvt) that uses
  libvirt snapshots quite a bit. I noticed after upgrading to trusty
  some time ago that qemu 1.7 (and the qemu 2.0 in the candidate ppa)
  has had stability problems such that the disk/partition table seems to
  be corrupted after removing a libvirt snapshot and then creating
  another with the same name. I don't have a very simple reproducer, but
  had enough that hallyn suggested I file a bug. First off:

  qemu-kvm 2.0~git-20140307.4c288ac-0ubuntu2

  $ cat /proc/version_signature
  Ubuntu 3.13.0-16.36-generic 3.13.5

  $ qemu-img info ./forhallyn-trusty-amd64.img
  image: ./forhallyn-trusty-amd64.img
  file format: qcow2
  virtual size: 8.0G (8589934592 bytes)
  disk size: 4.0G
  cluster_size: 65536
  Format specific information:
      compat: 0.10

  Steps to reproduce:
  1. create a virtual machine. For a simplified reproducer, I used virt-manager with:
    OS type: Linux
    Version: Ubuntu 14.04
    Memory: 768
    CPUs: 1

    Select managed or existing (Browse, new volume)
      Create a new storage volume:
        qcow2
        Max capacity: 8192
        Allocation: 0

    Advanced:
      NAT
      kvm
      x86_64
      firmware: default

  2. install a VM. I used trusty-desktop-amd64.iso from Jan 23 since it
  seems like I can hit the bug more reliably if I have lots of updates
  in a dist-upgrade. I have seen this with lucid-trusty guests that are
  i386 and amd64. After the install, reboot and then cleanly shutdown

  3. Backup the image file somewhere since steps 1 and 2 take a while :)

  4. Execute the following commands which are based on what our uvt tool
  does:

  $ virsh snapshot-create-as forhallyn-trusty-amd64 pristine "uvt snapshot"
  $ virsh snapshot-current --name forhallyn-trusty-amd64
  pristine
  $ virsh start forhallyn-trusty-amd64
  $ virsh snapshot-list forhallyn-trusty-amd64 # this is showing as shutoff after start, this might be different with qemu 1.5

  in guest:
  sudo apt-get update
  sudo apt-get dist-upgrade
  780 upgraded...
  shutdown -h now

  $ virsh snapshot-delete forhallyn-trusty-amd64 pristine --children
  $ virsh snapshot-create-as forhallyn-trusty-amd64 pristine "uvt snapshot"

  $ virsh start forhallyn-trusty-amd64 # this command works, but there
  is often disk corruption

  The idea behind the above is to create a new VM with a pristine
  snapshot that we could revert later if we wanted. Instead, we boot the
  VM, run apt-get dist-upgrade, cleanly shutdown and then remove the old
  'pristine' snapshot and create a new 'pristine' snapshot. The
  intention is to update the VM and the pristine snapshot so that when
  we boot the next time, we boot from the updated VM and can revert back
  to the updated VM.

  After running 'virsh start' after doing snapshot-delete/snapshot-
  create-as, the disk may be corrupted. This can be seen with grub
  failing to find .mod files, the kernel not booting, init failing, etc.

  This does not seem to be related to the machine type used. Ie, pc-
  i440fx-1.5, pc-i440fx-1.7 and pc-i440fx-2.0 all fail with qemu 2.0,
  pc-i440fx-1.5 and pc-i440fx-1.7 fail with qemu 1.7 and pc-i440fx-1.5
  works fine with qemu 1.5.

  Only workaround I know if is to downgrade qemu to 1.5.0+dfsg-
  3ubuntu5.4 from Ubuntu 13.10.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1292234/+subscriptions

[Qemu-devel] [Bug 1292234] Re: qcow2 image corruption in trusty (qemu 1.7 and 2.0 candidate)

[Chris J Arges]

Serge,
So I was able to just compile my own qemu and test with that.

I did attempt a reverse bisect, and was able to reproduce as early as v1.1 and also reproduce on master HEAD.
v1.0 was inconclusive because qcow2 format I made with the newer binary seemed to be incompatible with v1.0; however from Jamies testing this seems to be a working version; so I'd say somewhere between v1.0.0, v1.1.0 lies the original change that enabled this issue. As I've been unable to reproduce this without virsh, reverse bisecting and using older qemu versions is a bit challenging as machine types change, features virsh wants to use aren't available, etc.

Another interesting thing I tested today was I was able to reproduce
with ext4 with extents disabled; maybe that gives more clues. Just to
make sure I wasn't crazy, mkfs'd the partition to vanilla ext4 and
iterated for most of the afternoon with no failures.

My next steps are going to be enabling verbose output for qcow2, looking
more deeply into what gets corrupted in the file, and  turning on host
filesystem debugging.

--chris

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1292234

Title:
  qcow2 image corruption in trusty (qemu 1.7 and 2.0 candidate)

Status in QEMU:
  New
Status in qemu package in Ubuntu:
  Confirmed

Bug description:
  The security team uses a tool (http://bazaar.launchpad.net/~ubuntu-
  bugcontrol/ubuntu-qa-tools/master/view/head:/vm-tools/uvt) that uses
  libvirt snapshots quite a bit. I noticed after upgrading to trusty
  some time ago that qemu 1.7 (and the qemu 2.0 in the candidate ppa)
  has had stability problems such that the disk/partition table seems to
  be corrupted after removing a libvirt snapshot and then creating
  another with the same name. I don't have a very simple reproducer, but
  had enough that hallyn suggested I file a bug. First off:

  qemu-kvm 2.0~git-20140307.4c288ac-0ubuntu2

  $ cat /proc/version_signature
  Ubuntu 3.13.0-16.36-generic 3.13.5

  $ qemu-img info ./forhallyn-trusty-amd64.img
  image: ./forhallyn-trusty-amd64.img
  file format: qcow2
  virtual size: 8.0G (8589934592 bytes)
  disk size: 4.0G
  cluster_size: 65536
  Format specific information:
      compat: 0.10

  Steps to reproduce:
  1. create a virtual machine. For a simplified reproducer, I used virt-manager with:
    OS type: Linux
    Version: Ubuntu 14.04
    Memory: 768
    CPUs: 1

    Select managed or existing (Browse, new volume)
      Create a new storage volume:
        qcow2
        Max capacity: 8192
        Allocation: 0

    Advanced:
      NAT
      kvm
      x86_64
      firmware: default

  2. install a VM. I used trusty-desktop-amd64.iso from Jan 23 since it
  seems like I can hit the bug more reliably if I have lots of updates
  in a dist-upgrade. I have seen this with lucid-trusty guests that are
  i386 and amd64. After the install, reboot and then cleanly shutdown

  3. Backup the image file somewhere since steps 1 and 2 take a while :)

  4. Execute the following commands which are based on what our uvt tool
  does:

  $ virsh snapshot-create-as forhallyn-trusty-amd64 pristine "uvt snapshot"
  $ virsh snapshot-current --name forhallyn-trusty-amd64
  pristine
  $ virsh start forhallyn-trusty-amd64
  $ virsh snapshot-list forhallyn-trusty-amd64 # this is showing as shutoff after start, this might be different with qemu 1.5

  in guest:
  sudo apt-get update
  sudo apt-get dist-upgrade
  780 upgraded...
  shutdown -h now

  $ virsh snapshot-delete forhallyn-trusty-amd64 pristine --children
  $ virsh snapshot-create-as forhallyn-trusty-amd64 pristine "uvt snapshot"

  $ virsh start forhallyn-trusty-amd64 # this command works, but there
  is often disk corruption

  The idea behind the above is to create a new VM with a pristine
  snapshot that we could revert later if we wanted. Instead, we boot the
  VM, run apt-get dist-upgrade, cleanly shutdown and then remove the old
  'pristine' snapshot and create a new 'pristine' snapshot. The
  intention is to update the VM and the pristine snapshot so that when
  we boot the next time, we boot from the updated VM and can revert back
  to the updated VM.

  After running 'virsh start' after doing snapshot-delete/snapshot-
  create-as, the disk may be corrupted. This can be seen with grub
  failing to find .mod files, the kernel not booting, init failing, etc.

  This does not seem to be related to the machine type used. Ie, pc-
  i440fx-1.5, pc-i440fx-1.7 and pc-i440fx-2.0 all fail with qemu 2.0,
  pc-i440fx-1.5 and pc-i440fx-1.7 fail with qemu 1.7 and pc-i440fx-1.5
  works fine with qemu 1.5.

  Only workaround I know if is to downgrade qemu to 1.5.0+dfsg-
  3ubuntu5.4 from Ubuntu 13.10.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1292234/+subscriptions

[Qemu-devel] [Bug 1292234] Re: qcow2 image corruption in trusty (qemu 1.7 and 2.0 candidate)

[Chris J Arges]

** Changed in: qemu (Ubuntu)
       Status: Confirmed => In Progress

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1292234

Title:
  qcow2 image corruption in trusty (qemu 1.7 and 2.0 candidate)

Status in QEMU:
  New
Status in qemu package in Ubuntu:
  In Progress

Bug description:
  The security team uses a tool (http://bazaar.launchpad.net/~ubuntu-
  bugcontrol/ubuntu-qa-tools/master/view/head:/vm-tools/uvt) that uses
  libvirt snapshots quite a bit. I noticed after upgrading to trusty
  some time ago that qemu 1.7 (and the qemu 2.0 in the candidate ppa)
  has had stability problems such that the disk/partition table seems to
  be corrupted after removing a libvirt snapshot and then creating
  another with the same name. I don't have a very simple reproducer, but
  had enough that hallyn suggested I file a bug. First off:

  qemu-kvm 2.0~git-20140307.4c288ac-0ubuntu2

  $ cat /proc/version_signature
  Ubuntu 3.13.0-16.36-generic 3.13.5

  $ qemu-img info ./forhallyn-trusty-amd64.img
  image: ./forhallyn-trusty-amd64.img
  file format: qcow2
  virtual size: 8.0G (8589934592 bytes)
  disk size: 4.0G
  cluster_size: 65536
  Format specific information:
      compat: 0.10

  Steps to reproduce:
  1. create a virtual machine. For a simplified reproducer, I used virt-manager with:
    OS type: Linux
    Version: Ubuntu 14.04
    Memory: 768
    CPUs: 1

    Select managed or existing (Browse, new volume)
      Create a new storage volume:
        qcow2
        Max capacity: 8192
        Allocation: 0

    Advanced:
      NAT
      kvm
      x86_64
      firmware: default

  2. install a VM. I used trusty-desktop-amd64.iso from Jan 23 since it
  seems like I can hit the bug more reliably if I have lots of updates
  in a dist-upgrade. I have seen this with lucid-trusty guests that are
  i386 and amd64. After the install, reboot and then cleanly shutdown

  3. Backup the image file somewhere since steps 1 and 2 take a while :)

  4. Execute the following commands which are based on what our uvt tool
  does:

  $ virsh snapshot-create-as forhallyn-trusty-amd64 pristine "uvt snapshot"
  $ virsh snapshot-current --name forhallyn-trusty-amd64
  pristine
  $ virsh start forhallyn-trusty-amd64
  $ virsh snapshot-list forhallyn-trusty-amd64 # this is showing as shutoff after start, this might be different with qemu 1.5

  in guest:
  sudo apt-get update
  sudo apt-get dist-upgrade
  780 upgraded...
  shutdown -h now

  $ virsh snapshot-delete forhallyn-trusty-amd64 pristine --children
  $ virsh snapshot-create-as forhallyn-trusty-amd64 pristine "uvt snapshot"

  $ virsh start forhallyn-trusty-amd64 # this command works, but there
  is often disk corruption

  The idea behind the above is to create a new VM with a pristine
  snapshot that we could revert later if we wanted. Instead, we boot the
  VM, run apt-get dist-upgrade, cleanly shutdown and then remove the old
  'pristine' snapshot and create a new 'pristine' snapshot. The
  intention is to update the VM and the pristine snapshot so that when
  we boot the next time, we boot from the updated VM and can revert back
  to the updated VM.

  After running 'virsh start' after doing snapshot-delete/snapshot-
  create-as, the disk may be corrupted. This can be seen with grub
  failing to find .mod files, the kernel not booting, init failing, etc.

  This does not seem to be related to the machine type used. Ie, pc-
  i440fx-1.5, pc-i440fx-1.7 and pc-i440fx-2.0 all fail with qemu 2.0,
  pc-i440fx-1.5 and pc-i440fx-1.7 fail with qemu 1.7 and pc-i440fx-1.5
  works fine with qemu 1.5.

  Only workaround I know if is to downgrade qemu to 1.5.0+dfsg-
  3ubuntu5.4 from Ubuntu 13.10.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1292234/+subscriptions

[Qemu-devel] [Bug 1292234] Re: qcow2 image corruption in trusty (qemu 1.7 and 2.0 candidate)

[Chris J Arges]

FWIW, just re-reproduced this with latest upstream kernel / qemu / fresh
qcow2 image.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1292234

Title:
  qcow2 image corruption in trusty (qemu 1.7 and 2.0 candidate)

Status in QEMU:
  New
Status in qemu package in Ubuntu:
  In Progress

Bug description:
  The security team uses a tool (http://bazaar.launchpad.net/~ubuntu-
  bugcontrol/ubuntu-qa-tools/master/view/head:/vm-tools/uvt) that uses
  libvirt snapshots quite a bit. I noticed after upgrading to trusty
  some time ago that qemu 1.7 (and the qemu 2.0 in the candidate ppa)
  has had stability problems such that the disk/partition table seems to
  be corrupted after removing a libvirt snapshot and then creating
  another with the same name. I don't have a very simple reproducer, but
  had enough that hallyn suggested I file a bug. First off:

  qemu-kvm 2.0~git-20140307.4c288ac-0ubuntu2

  $ cat /proc/version_signature
  Ubuntu 3.13.0-16.36-generic 3.13.5

  $ qemu-img info ./forhallyn-trusty-amd64.img
  image: ./forhallyn-trusty-amd64.img
  file format: qcow2
  virtual size: 8.0G (8589934592 bytes)
  disk size: 4.0G
  cluster_size: 65536
  Format specific information:
      compat: 0.10

  Steps to reproduce:
  1. create a virtual machine. For a simplified reproducer, I used virt-manager with:
    OS type: Linux
    Version: Ubuntu 14.04
    Memory: 768
    CPUs: 1

    Select managed or existing (Browse, new volume)
      Create a new storage volume:
        qcow2
        Max capacity: 8192
        Allocation: 0

    Advanced:
      NAT
      kvm
      x86_64
      firmware: default

  2. install a VM. I used trusty-desktop-amd64.iso from Jan 23 since it
  seems like I can hit the bug more reliably if I have lots of updates
  in a dist-upgrade. I have seen this with lucid-trusty guests that are
  i386 and amd64. After the install, reboot and then cleanly shutdown

  3. Backup the image file somewhere since steps 1 and 2 take a while :)

  4. Execute the following commands which are based on what our uvt tool
  does:

  $ virsh snapshot-create-as forhallyn-trusty-amd64 pristine "uvt snapshot"
  $ virsh snapshot-current --name forhallyn-trusty-amd64
  pristine
  $ virsh start forhallyn-trusty-amd64
  $ virsh snapshot-list forhallyn-trusty-amd64 # this is showing as shutoff after start, this might be different with qemu 1.5

  in guest:
  sudo apt-get update
  sudo apt-get dist-upgrade
  780 upgraded...
  shutdown -h now

  $ virsh snapshot-delete forhallyn-trusty-amd64 pristine --children
  $ virsh snapshot-create-as forhallyn-trusty-amd64 pristine "uvt snapshot"

  $ virsh start forhallyn-trusty-amd64 # this command works, but there
  is often disk corruption

  The idea behind the above is to create a new VM with a pristine
  snapshot that we could revert later if we wanted. Instead, we boot the
  VM, run apt-get dist-upgrade, cleanly shutdown and then remove the old
  'pristine' snapshot and create a new 'pristine' snapshot. The
  intention is to update the VM and the pristine snapshot so that when
  we boot the next time, we boot from the updated VM and can revert back
  to the updated VM.

  After running 'virsh start' after doing snapshot-delete/snapshot-
  create-as, the disk may be corrupted. This can be seen with grub
  failing to find .mod files, the kernel not booting, init failing, etc.

  This does not seem to be related to the machine type used. Ie, pc-
  i440fx-1.5, pc-i440fx-1.7 and pc-i440fx-2.0 all fail with qemu 2.0,
  pc-i440fx-1.5 and pc-i440fx-1.7 fail with qemu 1.7 and pc-i440fx-1.5
  works fine with qemu 1.5.

  Only workaround I know if is to downgrade qemu to 1.5.0+dfsg-
  3ubuntu5.4 from Ubuntu 13.10.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1292234/+subscriptions

[Qemu-devel] [Bug 1292234] Re: qcow2 image corruption on non-extent filesystems (ext3)

[Chris J Arges]

** Summary changed:

- qcow2 image corruption in trusty (qemu 1.7 and 2.0 candidate)
+ qcow2 image corruption on non-extent filesystems (ext3)

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1292234

Title:
  qcow2 image corruption on non-extent filesystems (ext3)

Status in QEMU:
  New
Status in qemu package in Ubuntu:
  In Progress

Bug description:
  The security team uses a tool (http://bazaar.launchpad.net/~ubuntu-
  bugcontrol/ubuntu-qa-tools/master/view/head:/vm-tools/uvt) that uses
  libvirt snapshots quite a bit. I noticed after upgrading to trusty
  some time ago that qemu 1.7 (and the qemu 2.0 in the candidate ppa)
  has had stability problems such that the disk/partition table seems to
  be corrupted after removing a libvirt snapshot and then creating
  another with the same name. I don't have a very simple reproducer, but
  had enough that hallyn suggested I file a bug. First off:

  qemu-kvm 2.0~git-20140307.4c288ac-0ubuntu2

  $ cat /proc/version_signature
  Ubuntu 3.13.0-16.36-generic 3.13.5

  $ qemu-img info ./forhallyn-trusty-amd64.img
  image: ./forhallyn-trusty-amd64.img
  file format: qcow2
  virtual size: 8.0G (8589934592 bytes)
  disk size: 4.0G
  cluster_size: 65536
  Format specific information:
      compat: 0.10

  Steps to reproduce:
  1. create a virtual machine. For a simplified reproducer, I used virt-manager with:
    OS type: Linux
    Version: Ubuntu 14.04
    Memory: 768
    CPUs: 1

    Select managed or existing (Browse, new volume)
      Create a new storage volume:
        qcow2
        Max capacity: 8192
        Allocation: 0

    Advanced:
      NAT
      kvm
      x86_64
      firmware: default

  2. install a VM. I used trusty-desktop-amd64.iso from Jan 23 since it
  seems like I can hit the bug more reliably if I have lots of updates
  in a dist-upgrade. I have seen this with lucid-trusty guests that are
  i386 and amd64. After the install, reboot and then cleanly shutdown

  3. Backup the image file somewhere since steps 1 and 2 take a while :)

  4. Execute the following commands which are based on what our uvt tool
  does:

  $ virsh snapshot-create-as forhallyn-trusty-amd64 pristine "uvt snapshot"
  $ virsh snapshot-current --name forhallyn-trusty-amd64
  pristine
  $ virsh start forhallyn-trusty-amd64
  $ virsh snapshot-list forhallyn-trusty-amd64 # this is showing as shutoff after start, this might be different with qemu 1.5

  in guest:
  sudo apt-get update
  sudo apt-get dist-upgrade
  780 upgraded...
  shutdown -h now

  $ virsh snapshot-delete forhallyn-trusty-amd64 pristine --children
  $ virsh snapshot-create-as forhallyn-trusty-amd64 pristine "uvt snapshot"

  $ virsh start forhallyn-trusty-amd64 # this command works, but there
  is often disk corruption

  The idea behind the above is to create a new VM with a pristine
  snapshot that we could revert later if we wanted. Instead, we boot the
  VM, run apt-get dist-upgrade, cleanly shutdown and then remove the old
  'pristine' snapshot and create a new 'pristine' snapshot. The
  intention is to update the VM and the pristine snapshot so that when
  we boot the next time, we boot from the updated VM and can revert back
  to the updated VM.

  After running 'virsh start' after doing snapshot-delete/snapshot-
  create-as, the disk may be corrupted. This can be seen with grub
  failing to find .mod files, the kernel not booting, init failing, etc.

  This does not seem to be related to the machine type used. Ie, pc-
  i440fx-1.5, pc-i440fx-1.7 and pc-i440fx-2.0 all fail with qemu 2.0,
  pc-i440fx-1.5 and pc-i440fx-1.7 fail with qemu 1.7 and pc-i440fx-1.5
  works fine with qemu 1.5.

  Only workaround I know if is to downgrade qemu to 1.5.0+dfsg-
  3ubuntu5.4 from Ubuntu 13.10.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1292234/+subscriptions

[Qemu-devel] [Bug 1292234] Re: qcow2 image corruption on non-extent filesystems (ext3)

[Chris J Arges]

** No longer affects: qemu

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1292234

Title:
  qcow2 image corruption on non-extent filesystems (ext3)

Status in qemu package in Ubuntu:
  In Progress

Bug description:
  The security team uses a tool (http://bazaar.launchpad.net/~ubuntu-
  bugcontrol/ubuntu-qa-tools/master/view/head:/vm-tools/uvt) that uses
  libvirt snapshots quite a bit. I noticed after upgrading to trusty
  some time ago that qemu 1.7 (and the qemu 2.0 in the candidate ppa)
  has had stability problems such that the disk/partition table seems to
  be corrupted after removing a libvirt snapshot and then creating
  another with the same name. I don't have a very simple reproducer, but
  had enough that hallyn suggested I file a bug. First off:

  qemu-kvm 2.0~git-20140307.4c288ac-0ubuntu2

  $ cat /proc/version_signature
  Ubuntu 3.13.0-16.36-generic 3.13.5

  $ qemu-img info ./forhallyn-trusty-amd64.img
  image: ./forhallyn-trusty-amd64.img
  file format: qcow2
  virtual size: 8.0G (8589934592 bytes)
  disk size: 4.0G
  cluster_size: 65536
  Format specific information:
      compat: 0.10

  Steps to reproduce:
  1. create a virtual machine. For a simplified reproducer, I used virt-manager with:
    OS type: Linux
    Version: Ubuntu 14.04
    Memory: 768
    CPUs: 1

    Select managed or existing (Browse, new volume)
      Create a new storage volume:
        qcow2
        Max capacity: 8192
        Allocation: 0

    Advanced:
      NAT
      kvm
      x86_64
      firmware: default

  2. install a VM. I used trusty-desktop-amd64.iso from Jan 23 since it
  seems like I can hit the bug more reliably if I have lots of updates
  in a dist-upgrade. I have seen this with lucid-trusty guests that are
  i386 and amd64. After the install, reboot and then cleanly shutdown

  3. Backup the image file somewhere since steps 1 and 2 take a while :)

  4. Execute the following commands which are based on what our uvt tool
  does:

  $ virsh snapshot-create-as forhallyn-trusty-amd64 pristine "uvt snapshot"
  $ virsh snapshot-current --name forhallyn-trusty-amd64
  pristine
  $ virsh start forhallyn-trusty-amd64
  $ virsh snapshot-list forhallyn-trusty-amd64 # this is showing as shutoff after start, this might be different with qemu 1.5

  in guest:
  sudo apt-get update
  sudo apt-get dist-upgrade
  780 upgraded...
  shutdown -h now

  $ virsh snapshot-delete forhallyn-trusty-amd64 pristine --children
  $ virsh snapshot-create-as forhallyn-trusty-amd64 pristine "uvt snapshot"

  $ virsh start forhallyn-trusty-amd64 # this command works, but there
  is often disk corruption

  The idea behind the above is to create a new VM with a pristine
  snapshot that we could revert later if we wanted. Instead, we boot the
  VM, run apt-get dist-upgrade, cleanly shutdown and then remove the old
  'pristine' snapshot and create a new 'pristine' snapshot. The
  intention is to update the VM and the pristine snapshot so that when
  we boot the next time, we boot from the updated VM and can revert back
  to the updated VM.

  After running 'virsh start' after doing snapshot-delete/snapshot-
  create-as, the disk may be corrupted. This can be seen with grub
  failing to find .mod files, the kernel not booting, init failing, etc.

  This does not seem to be related to the machine type used. Ie, pc-
  i440fx-1.5, pc-i440fx-1.7 and pc-i440fx-2.0 all fail with qemu 2.0,
  pc-i440fx-1.5 and pc-i440fx-1.7 fail with qemu 1.7 and pc-i440fx-1.5
  works fine with qemu 1.5.

  Only workaround I know if is to downgrade qemu to 1.5.0+dfsg-
  3ubuntu5.4 from Ubuntu 13.10.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1292234/+subscriptions