<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<div class="gmail_quote">On Oct 5, 2014 6:23 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">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.<br>
Sure, this can fails, but that should be handled by vzctl chkpnt/restore internally.<br>
<br>
> I know I'd like to try it.  The potential issue is when migrating between nodes<br>
> with different kernel versions/modules/configurations.  It would probably be<br>
> useful to detect those cases (as best we can), and either issue a warning, or<br>
> automatically switch to an offline migration, shutting down and starting up<br>
> before and after migration, respectively.  If such detection isn't feasible, perhaps<br>
> online migrations of CTs are something we shouldn't worry about.  We can only<br>
> control the environment to a certain extent.<br>
> On the other hand, a failed online migration ought to lead sysadmins to attempt<br>
> offline migration before giving up, so maybe we just let the migration fail and let<br>
> the sysadmin adapt their course of action accordingly.  Just some thoughts on it.<br>
</blockquote></div>