Re: [Qemu-devel] Qemu savevm and CPU soft lockup

[Benjamin Cleyet-Marrel <bcm@accelance.fr>]

[-- Attachment #1: Type: text/plain, Size: 3649 bytes --]





-------- Message initial --------
De: Nathan Baum <nathan@parenthephobia.org.uk>
À: Ben Accelance <bcm@accelance.fr>
Cc: qemu-devel@nongnu.org <qemu-devel@nongnu.org>
Sujet: Re: [Qemu-devel] Qemu savevm and CPU soft lockup
Date: Wed, 23 Sep 2009 23:21:00 +0100


On Wed, 2009-09-23 at 20:52 +0200, Ben Accelance wrote:
> 
> 
> Le 23 sept. 2009 à 20:19, Jamie Lokier <jamie@shareable.org> a écrit :
> 
> > Benjamin Cleyet-Marrel wrote:
> >>
> >>   Hi,
> >>   After further investigation, I figured out that when issuing a  
> >> savevm
> >>   command
> >>   the entire qemu process gets stuck on IO wait.
> >>   I can't issue any other commands on the monitor the process is  
> >> shown
> >>   as D and the guest is in softlockup state.
> >>   Looking at the way migrate (and the -d for detach I presume) is
> >>   working I suppose the same behaviour would be expected from the  
> >> savevm
> >>   function.
> >>   A savevm -d so that the qemu process would not be freezed while  
> >> saving
> >>   the data.
> >>   Sorry if I am just talking non sense but my snapshot on iscsi  
> >> storage
> >>   takes about 1 minutes.
> >>   which means that my guest are down for a minute or so which is not
> >>   ideal.
> >
> > This is normal savevm behaviour, and it is exactly the reason why
> > migrate-to-file is useful.  I would not be surprised if savevm is
> > changed to use migrate-to-file internally at some point, but it does
> > not look like happening soon.
> >
> > You might avoid the guest softlockup state by stopping the guest
> > ("stop" command) before savevm, and "cont" afterwards?
> >
> > Or the guest might get just as confused, as the clock still advances.
> >
> > -- Jamie
> >
> >
> Thanks for this, at least it clarifies things. Now sorry for the  
> pain , but how do you migrate to a file and then how do you restore  
> from the file ?
> Thanks
> Cheers

>The way I migrate-to-file is with
>
>  (qemu) migrate -d "exec:cat>file".
>
>and then restore with
>
>  $ qemu ... -incoming "exec:cat file"
>



Hi, 

I finaly found some time to investigate deeper on this.
this migrate_to_file is definitly not cutting it.
I am trying to do a daily snapshot of my vm without any interruption.
the migrate to file by itself  is not doing an synchroneous disque image
snapshot (provided that image file are qcow2)
so restoring the status without the proper data is useless.
The only way I found is to embedd all the save function and qemu-img
snapshot -c call in a shell script. but it is not very clean I would
say.

the dosavevm script  looklike this : 

#!/bin/sh
qemu-img snapshot -c statefile /vm/img/test2_20G_vdc.img &
qemu-img snapshot -c statefile /vm/img/test2_2G_swap.img &
qemu-img snapshot -c statefile /vm/img/test2_5G_vda.img &
cat  > /tmp/test.statefile


and to save my disk I do: 

#!/bin/sh
echo -e "\001c\nmigrate -d \"exec:/root/dosavevm\"\n\001c\n" | socat
STDIO UNIX:/var/run/libvirt/qemu/test.serial 
satus=""
while [ -z "$status" ]
do
	status=`echo -e "\001c\ninfo migrate\n\001c\n" | socat STDIO
UNIX:/var/run/libvirt/qemu/test.serial | grep completed`
	sleep 1
done
echo -e "\001c\ncont\n\001c\n" | socat STDIO
UNIX:/var/run/libvirt/qemu/test.serial 


Which is as hugly as it can get.
Finnaly restoring the data needs:
shutdown the guest 
applying the snapshot 
starting a new process with the correct parameters 

So back to my original problem.

Is there a way to perform a consitent backup of kvm vm without 60s
downtime an hugly CPU soft lockup ?

Thanks

Cheers
Ben 





[-- Attachment #2: Type: text/html, Size: 4785 bytes --]