qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Benjamin Cleyet-Marrel
Subject: Re: [Qemu-devel] Qemu savevm and CPU soft lockup
Date: Wed, 30 Sep 2009 10:53:38 +0200





-------- Message initial --------
De: Nathan Baum <address@hidden>
À: Ben Accelance <address@hidden>
Cc: address@hidden <address@hidden>
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 <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]