[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