Long lasting bug and huge update, but I think I got the root cause.
FYI, Windows 2003 is having a write cache enabled by default on disk
drivers. Even with virtio (see driver details, policies).
As a consequence, any DLL which is open could be corrupted if we try a
simple 'qemu-img convert' against the VM.
The proper way to do a live snapshot is to disable the writecache (and
goodbye good perfs!) and do the convert.
The other way is to stop the VM, perform a 'qemu-img snapshot', then
convert the snapshot.
Hope it can help other people.
-Sylvain
Le 14/02/2013 11:11, Sylvain Bauza a écrit :
Interesting point you mention. Even if qcow2 is read only, the image
is changing (especially, I'm running IIS with ASP support and VB DLLs)
while the snapshot is taken.
As asked in a second post, I'm running with latest Windows virtio
drivers, but I only apply a virtio driver update *after* running an
instance, not before taking the snapshot.
What I'll try : run an instance, update the driver, stop the instance,
do a qemu-img convert once the instance is stopped.
Le 14/02/2013 09:15, Stefan Hajnoczi a écrit :
On Wed, Feb 13, 2013 at 10:53:14AM +0100, Sylvain Bauza wrote:
As per documentation, Nova (Openstack Compute layer) is doing a
'qemu-img convert -s' against a running instance.
http://docs.openstack.org/trunk/openstack-compute/admin/content/creating-images-from-running-instances.html
That command will not corrupt the running instance because it opens the
image read-only.
It is possible that the new image is corrupted since qemu-img is reading
from a qcow2 file that is changing underneath it. However, the chance
is small as long as the snapshot isn't deleted while qemu-img convert is
running.
So this doesn't sound like the cause of the problems you are seeing.
Stefan
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
