[libvirt] Some problem with the save function

Daniel P. Berrange berrange at redhat.com
Wed Sep 16 21:14:17 UTC 2009


On Wed, Sep 16, 2009 at 11:09:59PM +0200, Daniel Berteaud wrote:
> Le mercredi 16 septembre 2009 à 21:36 +0100, Daniel P. Berrange a
> écrit :
> > On Wed, Sep 16, 2009 at 05:05:36PM +0200, Daniel Berteaud wrote:
> > > Hi everyone. This is my first post to this list, so excuse me if it's
> > > not the right place to poste info like this.
> > > 
> > > I've found some problems in qemu_driver.c in the latest versions of
> > > libvirt:
> > > 
> > > - the first problem was also present in 0.7.0. If we run qemu guests
> > > unprivileged, we cannot use the save function (virsh save
> > > guestname /path/to/file). The reason seems to be that libvirt first
> > > create the destination file to write the header and the XML definition.
> > > The file is owned by root with 600 permission. Then, we ask qemu to
> > > append the dump of the memory (via the migrate exec: call) to this file.
> > > This part doesn't work because the qemu user cannot write to this file.
> > > So we endup with a file which only contains the header and the XML, and
> > > the guest is stoped :/
> > 
> > Doh, that's a nice problem. You can work around it by editing
> > /etc/libvirt/qemu.conf and telling qemu to run as root:root
> > again.  For a real fix we'll need to make the save method 
> > run 'fchown' on the file descriptor after writing the header.
> > And then fchown it back to root:root once complete, to stop
> > any other guest overwriting it.
> 
> As I only use the save function in a script, I work around it by
> touching the file and chowning it to qemu:qemu before calling save, I
> sleep better when my guests runs with less privileges ;)
> 
> > 
> > > - the second problem is present since libvirt 0.7.1. Now that the saved
> > > file can be compressed, it seems we cannot save in a raw format any
> > > more. This is due to this part in the code (qemu_driver.c):
> > > 
> > > if (STREQ (prog, "raw"))
> > >         prog = "cat";
> > >     internalret = virAsprintf(&command, "migrate \"exec:"
> > >                               "%s -c >> '%s' 2>/dev/null\"", prog,
> > > safe_path);
> > > 
> > > which result in "migrate \"exec cat -c >> safe_path 2>/dev/null\""
> > > 
> > > But cat doesn't support the -c argument, so once again, the save fails,
> > > as we end up with a save file which only contains the header and the XML
> > > definition.
> > 
> > Wierd, I don't know where/when we gained a '-c' arg to cat but it
> > looks rather bogus. 
> 
> The change is in this patch :
> http://libvirt.org/git/?p=libvirt.git;a=commit;h=aec22258ef01d7cf36b031a42d9963b58171707e
> 
> > 
> > > - the third problem, is that restore doesn't work any more. I haven't
> > > dig it yet, but when I try to restore a guest using a saved file
> > > (uncompressed produced under libvirt 0.7.0), I've this error:
> > > 
> > > virsh restore /tmp/guest.state
> > > error: Failed to restore domain from /tmp/guest.state
> > > error: internal error unable to start guest: 
> > 
> > Hmm, bad error message :-(  We might also need todo a chown()
> > in the restore path to allow QEMU to read it. NB there is no
> > compatability between QEMU version, so if you have upgraded
> > your install of QEMU between the time you saved & restored
> > it is very likely to crash & burn.
> 
> I haven't upgraded qemu, just libvirt. And I must admit that I don't
> really know where and how to debug it, I'm very new to libvirt ;) (and I
> really don't know anything in C)
> 
> Would just like to know if someone could get it working in 0.7.1, or if
> there's a big bug somewhere in this release.

Ok, I'd recommend filing a bug report against libvirt then with at
least the folowing information

 - The guest XML file
 - The guest log from /var/log/libvirt/qemu/$GUEST.log after the
   restore failed
 - Edit /etc/libvirt/libvirtd.conf and set

     log_level=1
     log_filters="1:libvirt 1:qemu 1:util"
     log_outputs="1:file:/var/log/libvirt/daemon.log"

   and then restart libvirtd, and try the save/restore again. Then
   upload the log you get to the bug
 - Version of QEMU or KVM used

That ought to help us diagnose the problem futher

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|




More information about the libvir-list mailing list