On Thu, Oct 11, 2012 at 3:20 AM, Roy Golan <span dir="ltr"><<a href="mailto:rgolan@redhat.com" target="_blank">rgolan@redhat.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div><br>
since the VM run_on_vds was empty, the "confirm host..." didn't
clear its status because its not selected from the DB as one of
the host VMs. <br>
I'll try to dig in to see at what point this value was cleared -
probably around the failed migration.</div></div></blockquote><div><br></div><div>Cool. Let me know if you need anything else from me. Again, I have the USB stick from cloudhost02 when it failed, if there is a log for vdsmd or something that might have something useful in it, just send me the path.</div>
<div><br></div><div>Are transactions in use in the system anywhere, either in the DB or the app layer? If not, have they been considered? I ask because this seems like the kind of thing they would address nicely. Specifically, if migration recipient is up and happy, but does not confirm VM is up or migration in progress, and sender node is no longer responsive, roll back to assuming the VM is still running on sender. This would avoid the inconsistent state I had of not-down-but-not-running-on-any-responding-host either and allow "confirm host..." to clear the unknown state of the VM.</div>
<div><br></div><div>Sorry if I am stating the obvious or over simplifying. It has been a long time since I wrote any significant code. =)</div></div>