8:15 a.m.
Hi everyone.
I'm trying to auto-suspend my guests when the host shutdown using the
managedsave function introduced in libvirt 0.8.0.
If I manually managedsave all my guest, then manually start all of the
guest with virsh start <guest>, everything works as expected, the saved
state is restored.
But there's a problem with the autoboot option:
- I configure a guest to automatically start on host boot (virsh
autostart guest)
- I save this guest (virsh managedsave guest)
- I restart libvirt to simulate a host reboot
The guest is started normally, instead of loading the saved state (and
the saved state is still present
in /var/lib/libvirt/qemu/save/guest.save, which means next manual boot
will probably fails)
So, it looks like there's a difference in the way libvirt starts guests
between autoboot and a manual virsh start.
Anybody else have this issue ?
Is this a known issue ?
I'm running libvirt 0.8.1 on a CentOS 5.5 x86_64 box
Regards, Daniel
--
Daniel Berteaud
FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Technopôle Montesquieu
33650 MARTILLAC
Tel : 05 56 64 15 32
Fax : 05 56 64 15 32
Mail: daniel(a)firewall-services.com
Web : http://www.firewall-services.com
8:36 a.m.
Hi,
I'm trying to auto-suspend my guests when the host shutdown using
the
managedsave function introduced in libvirt 0.8.0.
FYI, I just posted a second version of libvirt-guests init script which seems
to be doing exactly the same thing...
So, it looks like there's a difference in the way libvirt starts
guests
between autoboot and a manual virsh start.
Ah, yes, the code path is different for both cases :-( This needs to be fixed,
thanks for spotting it.
Jirka
8:45 a.m.
Le mardi 18 mai 2010 à 15:36 +0200, Jiri Denemark a écrit :
Hi,
> I'm trying to auto-suspend my guests when the host shutdown using the
> managedsave function introduced in libvirt 0.8.0.
FYI, I just posted a second version of libvirt-guests init script which seems
to be doing exactly the same thing...
Yep, I saw that, I've actually written something like this on my own
server (but not very clean for now, that's why I haven't shared it yet)
> So, it looks like there's a difference in the way libvirt starts guests
> between autoboot and a manual virsh start.
Ah, yes, the code path is different for both cases :-( This needs to be fixed,
thanks for spotting it.
If this is fixed, then, the save/restore script could be much more
simple. All it have to do is a managedsave on every running or paused
guest. Then, when libvirt start on host boot, all the guest configured
to autoboot would be started, and restored from the saved state if
available, or normally started.
Guests which have been saved on shutdown, but not configured for
autoboot can stay stpped, until the admin start them manually (and then,
they will be restored from the saved state).
Regards
Jirka
--
Daniel Berteaud
FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Technopôle Montesquieu
33650 MARTILLAC
Tel : 05 56 64 15 32
Fax : 05 56 64 15 32
Mail: daniel(a)firewall-services.com
Web : http://www.firewall-services.com
8:39 a.m.
On Tue, May 18, 2010 at 03:15:48PM +0200, Daniel Berteaud wrote:
Hi everyone.
I'm trying to auto-suspend my guests when the host shutdown using the
managedsave function introduced in libvirt 0.8.0.
If I manually managedsave all my guest, then manually start all of the
guest with virsh start <guest>, everything works as expected, the saved
state is restored.
But there's a problem with the autoboot option:
- I configure a guest to automatically start on host boot (virsh
autostart guest)
- I save this guest (virsh managedsave guest)
- I restart libvirt to simulate a host reboot
The guest is started normally, instead of loading the saved state (and
the saved state is still present
in /var/lib/libvirt/qemu/save/guest.save, which means next manual boot
will probably fails)
So, it looks like there's a difference in the way libvirt starts guests
between autoboot and a manual virsh start.
Anybody else have this issue ?
Is this a known issue ?
I'm running libvirt 0.8.1 on a CentOS 5.5 x86_64 box
Regards, Daniel
You'll need the initscript support for the managed save feature,
patches for which are on-list now waiting for ACKs. Otherwise
"autostart" doesn't really know anything about your saved VMs, only
the ones you've set to autostart.
--Hugh
--
Daniel Berteaud
FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Technopôle Montesquieu
33650 MARTILLAC
Tel : 05 56 64 15 32
Fax : 05 56 64 15 32
Mail: daniel(a)firewall-services.com
Web : http://www.firewall-services.com
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
--
========================================================
Hugh Brock, hbrock(a)redhat.com, +1-215-564-3232
Deltacloud API + Portal http://deltacloud.org
Libvirt virtualization library http://libvirt.org
========================================================
8:40 a.m.
On Tue, May 18, 2010 at 03:15:48PM +0200, Daniel Berteaud wrote:
Hi everyone.
I'm trying to auto-suspend my guests when the host shutdown using the
managedsave function introduced in libvirt 0.8.0.
If I manually managedsave all my guest, then manually start all of the
guest with virsh start <guest>, everything works as expected, the saved
state is restored.
But there's a problem with the autoboot option:
- I configure a guest to automatically start on host boot (virsh
autostart guest)
- I save this guest (virsh managedsave guest)
- I restart libvirt to simulate a host reboot
The guest is started normally, instead of loading the saved state (and
the saved state is still present
in /var/lib/libvirt/qemu/save/guest.save, which means next manual boot
will probably fails)
So, it looks like there's a difference in the way libvirt starts guests
between autoboot and a manual virsh start.
Yep, there's a design bug in the way this is implemented in the QEMU driver.
The code that restores the snapshot is in the qemudDomainStart() method,
rather than qemudStartVMDaemon(). This means that when the guest is
autostarted, the snapshot restore is missed.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
8:47 a.m.
Le mardi 18 mai 2010 à 14:40 +0100, Daniel P. Berrange a écrit :
On Tue, May 18, 2010 at 03:15:48PM +0200, Daniel Berteaud wrote:
>
> So, it looks like there's a difference in the way libvirt starts guests
> between autoboot and a manual virsh start.
Yep, there's a design bug in the way this is implemented in the QEMU driver.
The code that restores the snapshot is in the qemudDomainStart() method,
rather than qemudStartVMDaemon(). This means that when the guest is
autostarted, the snapshot restore is missed.
Ok, thanks for the clarification. I'll try to look at this, but I don't
think I'll be able to fixe anything ;) so I'll wait a little more.
Regards, Daniel
--
Daniel Berteaud
FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Technopôle Montesquieu
33650 MARTILLAC
Tel : 05 56 64 15 32
Fax : 05 56 64 15 32
Mail: daniel(a)firewall-services.com
Web : http://www.firewall-services.com
9:56 a.m.
Le mardi 18 mai 2010 à 14:40 +0100, Daniel P. Berrange a écrit :
On Tue, May 18, 2010 at 03:15:48PM +0200, Daniel Berteaud wrote:
> So, it looks like there's a difference in the way libvirt starts guests
> between autoboot and a manual virsh start.
Yep, there's a design bug in the way this is implemented in the QEMU driver.
The code that restores the snapshot is in the qemudDomainStart() method,
rather than qemudStartVMDaemon(). This means that when the guest is
autostarted, the snapshot restore is missed.
btw, there's another bug in the managedsave function I think: it doesn't
honor the save_image_format directive in qemu.conf
Regards, Daniel
--
Daniel Berteaud
FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Technopôle Montesquieu
33650 MARTILLAC
Tel : 05 56 64 15 32
Fax : 05 56 64 15 32
Mail: daniel(a)firewall-services.com
Web : http://www.firewall-services.com
5303
days inactive
5303
days old
6 comments
4 participants
participants (4)
-
Daniel Berteaud -
Daniel P. Berrange -
Hugh O. Brock -
Jiri Denemark