Hi,<div><br></div><div>This is the problem:</div><div><br></div><div>A shutdown action is triggered and shutdown process starts. The VM can not proceed to the next state (epilog, i.e. image transfer) until the VM has been totally stopped. Note that start a file movement operation while the VM is shutting down will lead to a corrupted image. Also note that the shutdown operation succeed instantaneously, well before the VM is really shutdown.</div>
<div><br></div><div>Solution:</div><div><br></div><div>The driver has to notify a shutdown success when the VM has been completely shutdown, i.e. it disappears from the hypervisor. Now, we need a timeout or we may end up waiting for ever for the VM to shutdown (e.g. if the VM has no acpi).</div>
<div><br></div><div>About reverting to running:</div><div><br></div><div>We assume that a VM is valuable so we rather be play safe . If the VM returns to running, it will be monitored and it is not really there it will be moved to unknown.</div>
<div><br></div><div><br></div><div>Cheers</div><div><br></div><div>Ruben</div><div><br></div><div><br></div><div> <br><br><div class="gmail_quote">On Wed, Oct 27, 2010 at 5:06 PM, Rich Wellner <span dir="ltr"><<a href="mailto:rkw@objenv.com">rkw@objenv.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Yeah, even better. I like this idea if there has to be a timeout.<br>
<br>
Though the more I think about it, the less I'm sure I understand why the timeout needs to exist nor why the state reverts to Running instead of Unknown once it triggers. Seems like maybe the state model needs another node "Shutdown Failed" or something for when the guest fails to disappear (for example if acpid isn't installed). Otherwise an administrator looking at 'onevm list' doesn't get a complete picture of how the current state differs from the desired state.<br>
<br>
So, what was the use case for having the time out in the first place?<br>
<br>
rw2<div><div></div><div class="h5"><br>
<br>
On 10/27/10 9:50 AM, Igor Rosenberg wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Humble opinion: shutdown-time is VM specific. I may have, running concurrently, an image of shutdown time ~ 10s (a tiny linux), and another with shutdown time ~ 5 minutes or more (fat J2EE container with remote DB dependencies).<br>
<br>
The shutdown-time would typically be known by the person who created originally the VM image. So can this information be embed in the image itself? If not, the VM template would be another likely place. But having a maximum value for all possible images may create problems as VMs grow in embed service complexity.<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:users-bounces@lists.opennebula.org" target="_blank">users-bounces@lists.opennebula.org</a> [mailto:<a href="mailto:users-bounces@lists.opennebula.org" target="_blank">users-bounces@lists.opennebula.org</a>] On Behalf Of Rich Wellner<br>
Sent: miércoles, 27 de octubre de 2010 16:19<br>
To: Tino Vazquez<br>
Cc: <a href="mailto:users@lists.opennebula.org" target="_blank">users@lists.opennebula.org</a><br>
Subject: Re: [one-users] Unknown state<br>
<br>
Ok, I'll check that out. FYI: my RHEL 5.5 machines on reasonably<br>
capable hardware take longer than that default. Might be worth<br>
considering a longer default.<br>
<br>
rw2<br>
<br>
On 10/27/10 8:33 AM, Tino Vazquez wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Rich,<br>
<br>
OpenNebula ceases its monitoring when the VM enters the shutdown<br>
state. What is probably happening is that the VM takes more time to<br>
shutdown than the default timeout, which is 40 seconds (20 iterations<br>
over a 2 seconds sleep), so for OpenNebula is like if the shutdown<br>
failed. This timeout default can be adjusted in<br>
$ONE_LOCATION/bin/remotes/vmm/kvm/shutdown.<br>
<br>
Best regards,<br>
<br>
-Tino<br>
<br>
--<br>
Constantino Vázquez Blanco | <a href="http://dsa-research.org/tinova" target="_blank">dsa-research.org/tinova</a><br>
Virtualization Technology Engineer / Researcher<br>
OpenNebula Toolkit | <a href="http://opennebula.org" target="_blank">opennebula.org</a><br>
<br>
<br>
<br>
On Wed, Oct 27, 2010 at 1:08 AM, Rich Wellner<<a href="mailto:rkw@objenv.com" target="_blank">rkw@objenv.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hey guys,<br>
<br>
I have monitoring turned down to a minute so that I don't have much latency<br>
on my management while we're doing testing. As a result, when I do a<br>
shutdown on a vm sometimes the shutdown isn't complete before the next<br>
monitoring update. What ends up happening is that the state of the machine<br>
goes from running to shutdown, then a bit later to running again. Finally,<br>
when the guest shutdown actually complete, the state goes to unknow because<br>
One doesn't know why the machine disappeared.<br>
<br>
It would be better if this race condition were handled more elegantly and<br>
One could tolerate that the machine took a while to shutdown. As is a<br>
manual clean-up has to happen. I have also confirmed that my one minute<br>
monitor cycle only makes the problem more likely. If, by coincidence,<br>
someone asks One to shutdown a vm slightly before the monitor thread kicks<br>
off, this issue shows up. So it seems any machine that is shutdown where<br>
timeToShutdown> timeUntilMonitorRefresh will end up in an unknown state.<br>
<br>
rw2<br>
<br>
<br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opennebula.org" target="_blank">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>
<br>
</blockquote></blockquote>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opennebula.org" target="_blank">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>
This e-mail and the documents attached are confidential and intended<br>
solely for the addressee; it may also be privileged. If you receive<br>
this e-mail in error, please notify the sender immediately and destroy it.<br>
As its integrity cannot be secured on the Internet, the Atos Origin<br>
group liability cannot be triggered for the message content. Although<br>
the sender endeavours to maintain a computer virus-free network,<br>
the sender does not warrant that this transmission is virus-free and<br>
will not be liable for any damages resulting from any virus transmitted.<br>
<br>
Este mensaje y los ficheros adjuntos pueden contener informacion confidencial<br>
destinada solamente a la(s) persona(s) mencionadas anteriormente<br>
pueden estar protegidos por secreto profesional.<br>
Si usted recibe este correo electronico por error, gracias por informar<br>
inmediatamente al remitente y destruir el mensaje.<br>
Al no estar asegurada la integridad de este mensaje sobre la red, Atos Origin<br>
no se hace responsable por su contenido. Su contenido no constituye ningun<br>
compromiso para el grupo Atos Origin, salvo ratificacion escrita por ambas partes.<br>
Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor<br>
no puede garantizar nada al respecto y no sera responsable de cualesquiera<br>
danos que puedan resultar de una transmision de virus.<br>
------------------------------------------------------------------<br>
</blockquote>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opennebula.org" target="_blank">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>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Dr. Ruben Santiago Montero<br>Associate Professor (Profesor Titular), Complutense University of Madrid<br><br>URL: <a href="http://dsa-research.org/doku.php?id=people:ruben" target="_blank">http://dsa-research.org/doku.php?id=people:ruben</a><br>
Weblog: <a href="http://blog.dsa-research.org/?author=7" target="_blank">http://blog.dsa-research.org/?author=7</a><br>
</div>