We've never had this issue before, and do run a lot of VMs that get shutdown fairly regularly. I think the issue may be related somehow to the snapshot and/or disk size vs virtual size, but I'm not 100% sure.
On Thu, Jun 2, 2016 at 3:30 AM, Dominique Ramaekers < dominique.ramaek...@cometal.be> wrote: > > > > -----Oorspronkelijk bericht----- > > Van: Qemu-discuss [mailto:qemu-discuss- > > bounces+dominique.ramaekers=cometal...@nongnu.org] Namens Jakob Bohm > > Verzonden: woensdag 1 juni 2016 20:30 > > Aan: Jacob Godin > > CC: qemu-discuss@nongnu.org > > Onderwerp: Re: [Qemu-discuss] Disk Corruption > .... > > > > > > > > > > How did you "power off" the VM? > > > > > > > > > Using virsh shutdown > > > > > > > > > Did you use some qemu management tool (which one and which > version)? > > > > > > > > > libvirt version 1.2.2 (1.2.2-0ubuntu13.1.17) > > > > > > > > > Did you kill the qemu process? > > > > > > > > > We made sure it was dead before taking the snap. > > > > Not clear: Did you *kill* the qemu process or did it exit all by itself > when you > > shut down the guest? > > > > And the same question back when you made the snapshot. > > > > > > > > > > > Did you do a "clean" shutdown of the Guest OS and wait for the > Guest > > > OS to tell the qemu process to exit on its own? > > > > > > > > > Yes, virsh shutdown issues a safe shutdown via ACPI > > > > Other people on this list may know more about what that libvirt version > does in > > this situation (beside the initial "polite" request via a qemu command to > > generate the ACPI event). > > > ... > > I want to note: > Two times I also had a corrupted disk after a shutdown with virsh > shutdown. I had the feeling virsh destroyed the domain when the shutdown > took to long. I know this shouldn't be the behavior of virsh shutdown, but > still... Now I use commands like this to be sure virsh only uses safe > shutdown methods: > $ virsh shutdown $VM --mode=agent || virsh shutdown $VM --mode=acpi > # if the shutdown trough the agent doesn't work, do a acpi shutdown... >