hi, if i use xen with xendomain it's possible to save and restore guest state. if i use libvirt it's not working (at least by default with kvm). i mean if i stop or restart libvirtd all guests a stopped and even if i restart libvirtd i've to start all guests manually. imho this's a very essential feature. what is the reason this not working with libvirtd?: - this feature is missing from libvirtd? or

- this feature is not turned on by default? or

Daniel P. Berrange wrote: > On Sat, Oct 06, 2007 at 02:29:39PM +0200, Farkas Levente wrote: >> hi, >> if i use xen with xendomain it's possible to save and restore guest >> state. if i use libvirt it's not working (at least by default with kvm). >> i mean if i stop or restart libvirtd all guests a stopped and even if i >> restart libvirtd i've to start all guests manually. imho this's a very >> essential feature. what is the reason this not working with libvirtd?: >> - this feature is missing from libvirtd? or > > You can set KVM/QEMU guests to autostart with > > virsh autostart {NAME|ID|UUID} thanks, but go back to my first question. afais /etc/init.d/libvirtd simple kill libvirtd, but virsh has a command save/restore. wouldn't be it's much better to save guest's state on stop, restore on start in stead of start if there is a saved state. i can send a patch to the /etc/init.d/libvirtd, just would like to know is there any reason it's not that way? anyway xendomains do it in the save way.

Daniel P. Berrange wrote: > On Mon, Oct 08, 2007 at 04:27:00PM +0200, Farkas Levente wrote: >> Daniel P. Berrange wrote: >>> On Sat, Oct 06, 2007 at 02:29:39PM +0200, Farkas Levente wrote: >>>> hi, >>>> if i use xen with xendomain it's possible to save and restore guest >>>> state. if i use libvirt it's not working (at least by default with kvm). >>>> i mean if i stop or restart libvirtd all guests a stopped and even if i >>>> restart libvirtd i've to start all guests manually. imho this's a very >>>> essential feature. what is the reason this not working with libvirtd?: >>>> - this feature is missing from libvirtd? or >>> You can set KVM/QEMU guests to autostart with >>> >>> virsh autostart {NAME|ID|UUID} >> thanks, but go back to my first question. afais /etc/init.d/libvirtd >> simple kill libvirtd, but virsh has a command save/restore. wouldn't be >> it's much better to save guest's state on stop, restore on start in >> stead of start if there is a saved state. i can send a patch to the >> /etc/init.d/libvirtd, just would like to know is there any reason it's >> not that way? anyway xendomains do it in the save way. > The save/restore capability is currently only available in the KVM-ified > version of QEMU. We could make it try to save, and failing that destroy > the guest. The xendomains scripts isn't a good model to emulate though. > The autostart/kill functionality is part of the libvirt daemon itself. Any > save/restore capability would be best integrated there for those who like to save and restore guest at libvirtd stop and start i attached a patch we use to for it. it's based on xen's sripts. LIBVIRTD_AUTO_ONLY still not implemented but the sysconfig file already contains it. if you like to set the default behavior to the current then set LIBVIRTD_RESTORE to false. imho it'd be useful to include in the upstream libvirtd too.

On Fri, Oct 19, 2007 at 01:56:10PM +0200, Farkas Levente wrote: > Farkas Levente wrote: >> Daniel P. Berrange wrote: >>> The save/restore capability is currently only available in the KVM-ified >>> version of QEMU. We could make it try to save, and failing that destroy >>> the guest. The xendomains scripts isn't a good model to emulate though. >>> The autostart/kill functionality is part of the libvirt daemon itself. Any >>> save/restore capability would be best integrated there >> for those who like to save and restore guest at libvirtd stop and start >> i attached a patch we use to for it. it's based on xen's sripts. >> LIBVIRTD_AUTO_ONLY still not implemented but the sysconfig file already >> contains it. if you like to set the default behavior to the current then >> set LIBVIRTD_RESTORE to false. >> imho it'd be useful to include in the upstream libvirtd too. >> > and the patch:-) As I mentioned above, doing this in the init script is a bad idea because it does not interact well with domain autostart. The libvirt dameon itself will autostart domains when it starts. So you may be saving the guests at shutdown, but at the next boot any which are marked autostart will be started fresh & the subsequent restore for them will fail since they are already running. Doing this all correctly requires doing it in the daemon not the initscript.

Farkas Levente wrote: > Daniel P. Berrange wrote: >> On Fri, Oct 19, 2007 at 01:56:10PM +0200, Farkas Levente wrote: >>> Farkas Levente wrote: >>>> Daniel P. Berrange wrote: >>>>> The save/restore capability is currently only available in the >>>>> KVM-ified >>>>> version of QEMU. We could make it try to save, and failing that >>>>> destroy >>>>> the guest. The xendomains scripts isn't a good model to emulate >>>>> though. >>>>> The autostart/kill functionality is part of the libvirt daemon >>>>> itself. Any >>>>> save/restore capability would be best integrated there >>>> for those who like to save and restore guest at libvirtd stop and >>>> start >>>> i attached a patch we use to for it. it's based on xen's sripts. >>>> LIBVIRTD_AUTO_ONLY still not implemented but the sysconfig file >>>> already >>>> contains it. if you like to set the default behavior to the current >>>> then >>>> set LIBVIRTD_RESTORE to false. >>>> imho it'd be useful to include in the upstream libvirtd too. >>>> >>> and the patch:-) >> As I mentioned above, doing this in the init script is a bad idea >> because >> it does not interact well with domain autostart. The libvirt dameon >> itself >> will autostart domains when it starts. So you may be saving the guests >> at shutdown, but at the next boot any which are marked autostart will be >> started fresh & the subsequent restore for them will fail since they are >> already running. Doing this all correctly requires doing it in the >> daemon >> not the initscript. > > yes, but currently it's not implemented:-( but if you don't autostart > any guest (which is the current default) my patch at least working until > it'll be implemented. The problem is that if we put in your patch, we add a set of configuration options which we'll have to keep supporting forever, even when the 'proper' solution is done (whatever that might be).