[pve-devel] [PATCH 1/4] Add CT suspend/resume support via PVE2 API

Daniel Hunsaker danhunsaker at gmail.com
Sun Oct 5 19:32:54 CEST 2014


It would simply fail, and not necessarily in a way that the reason makes
sense to the user.  But that answers my question on how to handle such
scenarios.

KVM doesn't have the same issue, since the entire system is virtualized in
that case.  So it may not be obvious why CT migrations are failing, even
while VM migrations succeed.  That's all I was concerned about, really.
On Oct 5, 2014 6:23 AM, "Dietmar Maurer" <dietmar at proxmox.com> wrote:

> I don't really understand what you talk about. If you suspend to disk, you
> also need/should transfer that state when you migrate the VM. This is
> unrelated to online migration.
> Sure, this can fails, but that should be handled by vzctl chkpnt/restore
> internally.
>
> > I know I'd like to try it.  The potential issue is when migrating
> between nodes
> > with different kernel versions/modules/configurations.  It would
> probably be
> > useful to detect those cases (as best we can), and either issue a
> warning, or
> > automatically switch to an offline migration, shutting down and starting
> up
> > before and after migration, respectively.  If such detection isn't
> feasible, perhaps
> > online migrations of CTs are something we shouldn't worry about.  We can
> only
> > control the environment to a certain extent.
> > On the other hand, a failed online migration ought to lead sysadmins to
> attempt
> > offline migration before giving up, so maybe we just let the migration
> fail and let
> > the sysadmin adapt their course of action accordingly.  Just some
> thoughts on it.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.proxmox.com/pipermail/pve-devel/attachments/20141005/a3b3510c/attachment.htm>


More information about the pve-devel mailing list