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).
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. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Rich Wellner Sent: miércoles, 27 de octubre de 2010 16:19 To: Tino Vazquez Cc: [email protected] Subject: Re: [one-users] Unknown state Ok, I'll check that out. FYI: my RHEL 5.5 machines on reasonably capable hardware take longer than that default. Might be worth considering a longer default. rw2 On 10/27/10 8:33 AM, Tino Vazquez wrote: > Hi Rich, > > OpenNebula ceases its monitoring when the VM enters the shutdown > state. What is probably happening is that the VM takes more time to > shutdown than the default timeout, which is 40 seconds (20 iterations > over a 2 seconds sleep), so for OpenNebula is like if the shutdown > failed. This timeout default can be adjusted in > $ONE_LOCATION/bin/remotes/vmm/kvm/shutdown. > > Best regards, > > -Tino > > -- > Constantino Vázquez Blanco | dsa-research.org/tinova > Virtualization Technology Engineer / Researcher > OpenNebula Toolkit | opennebula.org > > > > On Wed, Oct 27, 2010 at 1:08 AM, Rich Wellner<[email protected]> wrote: >> Hey guys, >> >> I have monitoring turned down to a minute so that I don't have much latency >> on my management while we're doing testing. As a result, when I do a >> shutdown on a vm sometimes the shutdown isn't complete before the next >> monitoring update. What ends up happening is that the state of the machine >> goes from running to shutdown, then a bit later to running again. Finally, >> when the guest shutdown actually complete, the state goes to unknow because >> One doesn't know why the machine disappeared. >> >> It would be better if this race condition were handled more elegantly and >> One could tolerate that the machine took a while to shutdown. As is a >> manual clean-up has to happen. I have also confirmed that my one minute >> monitor cycle only makes the problem more likely. If, by coincidence, >> someone asks One to shutdown a vm slightly before the monitor thread kicks >> off, this issue shows up. So it seems any machine that is shutdown where >> timeToShutdown> timeUntilMonitorRefresh will end up in an unknown state. >> >> rw2 >> >> >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org >> >> _______________________________________________ Users mailing list [email protected] http://lists.opennebula.org/listinfo.cgi/users-opennebula.org ------------------------------------------------------------------ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. Este mensaje y los ficheros adjuntos pueden contener informacion confidencial destinada solamente a la(s) persona(s) mencionadas anteriormente pueden estar protegidos por secreto profesional. Si usted recibe este correo electronico por error, gracias por informar inmediatamente al remitente y destruir el mensaje. Al no estar asegurada la integridad de este mensaje sobre la red, Atos Origin no se hace responsable por su contenido. Su contenido no constituye ningun compromiso para el grupo Atos Origin, salvo ratificacion escrita por ambas partes. Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor no puede garantizar nada al respecto y no sera responsable de cualesquiera danos que puedan resultar de una transmision de virus. ------------------------------------------------------------------ _______________________________________________ Users mailing list [email protected] http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
