Hi,<div><br></div><div>Instead of executing 'virsh create' manually in another host, you can use the 'onevm resubmit' action [1].</div><div>This can be done automatically using the fault tolerance hooks [2]</div>

<div><br></div><div>Regards</div><div><br></div><div>[1] <a href="http://opennebula.org/documentation:rel3.8:vm_guide_2#life-cycle_operations">http://opennebula.org/documentation:rel3.8:vm_guide_2#life-cycle_operations</a></div>

<div>[2] <a href="http://opennebula.org/documentation:rel3.8:ftguide">http://opennebula.org/documentation:rel3.8:ftguide</a><br clear="all">--<br>Carlos Martín, MSc<br>Project Engineer<br>OpenNebula - The Open-source Solution for Data Center Virtualization<div>

<span style="border-collapse:collapse;color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px"><a href="http://www.OpenNebula.org" target="_blank">www.OpenNebula.org</a> | <a href="mailto:cmartin@opennebula.org" target="_blank">cmartin@opennebula.org</a> | <a href="http://twitter.com/opennebula" target="_blank">@OpenNebula</a></span><span style="border-collapse:collapse;color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px"><a href="mailto:cmartin@opennebula.org" style="color:rgb(42,93,176)" target="_blank"></a></span></div>

<br>
<br><br><div class="gmail_quote">On Fri, Nov 16, 2012 at 10:58 PM, Ricardo Duarte <span dir="ltr"><<a href="mailto:rjtd21@hotmail.com" target="_blank">rjtd21@hotmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div><div dir="ltr">Hi there,<br><br>Something I find missing in OpenNebula is a "sync state" functionality.<br>OpenNebula could monitor hosts and update the relationships between instances and hosts dynamically.<br>

So, for example, when a host fails we could manually fix the problem by "virsh create" the deployments on a new server, and OpenNebula would pick the new host for the instances.<br>Currently, the machines stay as "UNKNOWN".<br>

<br>Also related is the potential danger "UNKNOWN" states present when the system datastore runs on shared storage.<br>So, on my last example:<br>- I would start the instances on a new host. <br>- Users on Sunstone would still see the machines as "UNKNOWN" and can restart the machines<br>

- Both instances would start writing on the same file, leading to corruption<br><br>To prevent that OpenNebula ccan/should make use of  sanlock. OpenNebula would be required to act as the lock manager.<br>By syncing state we could limit conflicts, and by using sanlock we could make it fail proof.<br>

<br>Regards,<br>Ricardo<br>                                     </div></div>
<br>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opennebula.org">Users@lists.opennebula.org</a><br>
<a href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org" target="_blank">http://lists.opennebula.org/listinfo.cgi/users-opennebula.org</a><br>
<br></blockquote></div><br></div>