<p dir="ltr">Actually, that part wasn't me, but since the answer is yes, I'll look into getting QEMU to save state to disk so we can do the rest.  :-) </p>
<p dir="ltr">And now to sleep, finally...</p>
<div class="gmail_quote">On Oct 3, 2014 2:53 AM, "Dietmar Maurer" <<a href="mailto:dietmar@proxmox.com">dietmar@proxmox.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> > 1.) Implement suspend/resume API<br>
> > 2.) add it to pvectl<br>
> > 3.) Implement suspend/resume GUI (extjs)<br>
> > 4.) Implement suspend/resume GUI (mobile)<br>
> Alright, I'll make that happen tomorrow.  Currently just after 02:00 here.  :-)<br>
<br>
Thanks!<br>
<br>
> > I also have some further ideas. Currently qemu suspend/resume does not<br>
> > save state to disk. It would be great to implement that also.<br>
> I'll have to research that some, but I should be able to write a patch for that as<br>
> well.<br>
> > Then implement an option in datacenter.cfg like:<br>
> ><br>
> > reboot: stop|suspend<br>
> ><br>
> > So that VMs are suspended while we reboot a host. What do you think?<br>
> That would probably save a *lot* of time bringing servers back up after<br>
> reboot.  I'll look into that as well, probably next week.<br>
<br>
OK<br>
<br>
> To go another step with that logic, I wonder if there might be a benefit to<br>
> modifying QEMU migrations so they suspend with state, transfer the suspended<br>
> VM, and resume on the destination node.<br>
<br>
This is how migrate works (basically). Or what is the difference?<br>
<br>
> I could see an advanced implementation where VM snapshots are taken<br>
> periodically, and if the node experiences a power failure, the VM could resume<br>
> from the snapshot.  HA failover could take advantage of the same snapshots in<br>
> the same way, thereby (hopefully) losing less data, and possibly resulting in less<br>
> downtime.  This would definitely need to be an option enabled on VMs that<br>
> would benefit from such an approach, rather than enabled universally, and is<br>
> advanced enough it might remain in the realm of third-party scripts or packages,<br>
> but it still might be useful.<br>
> Before I get too far into the QEMU suspend-with-state patch, I want to ask -<br>
> does OpenVZ support suspend-with-state?  Might be nice to support that in the<br>
> patch, too, if it does.<br>
<br>
You already implemented that!<br>
<br>
    chkpnt CTID [--dumpfile name]<br>
           This  command  saves  a  complete state of a running container to a<br>
           dump file, and stops the container. If an option --dumpfile is  not<br>
           set, default dump file name /vz/dump/Dump.CTID is used.<br>
<br>
</blockquote></div>