On 12/09/2012 02:55 PM, Adrian Gibanel wrote:
This is how I see it:
Engine should have an offline database of its assigned hosts and their state (With state I mean properties. One of these properties would be the auto-start one). So when a host starts the engine starts and then loops assigned virtual machines. While looping the virtual machines checs its auto-start property. If it's set to true it starts the virtual machine.
Not sure if what I am describing has an easy implementation with current oVirt architecture. Any comments from people who might understand better oVirt architecture on this use-case?
I think the hosts should rely the least possible on the management server.
my concern is how to make sure engine only starts VMs it should in this case.
------------------------------------------------------------------------
*De: *"Itamar Heim" <iheim@redhat.com> *Para: *"Adrian Gibanel" <adrian.gibanel@btactic.com> *CC: *"users" <users@ovirt.org> *Enviados: *Viernes, 7 de Diciembre 2012 19:39:26 *Asunto: *Re: [Users] Auto-start vms on boot?
On 12/07/2012 06:23 PM, Adrian Gibanel wrote: > My use case is that I just don't want to start manually the virtual machines when the host starts and, also, if the host is shutdown it should guest-shutdown the virtual machines. > > Any doc on that pin option? How one is supposed to pin a virtual machine to a host?
just to be clear, we still don't have the behavior i described. I just stated the only use case i'm familiar for a similar requirement. (pinning a VM to host is done via the edit vm dialog).
question on your use case - how would the engine know if the admin just shutdown a VM manually from a VM which should be auto started (should we add such a checkbox). in the use case i described, we would be adding a 'start/stop VM with host' for a VM pinned to a host.
> > Thank you. > > ----- Mensaje original ----- > >> On 12/06/2012 10:34 PM, Adrian Gibanel wrote: >>> It would seem that oVirt does not provide an standard way of >>> forcing boot of virtual machines at boot. >>> >>> Pools can have pre-started vms as stated here: >>> https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Virtualiza... >>> but pools imply state-less virtual machines and I am talking more >>> about normal virtual machines. >>> >>> I've found this script: >>> >>> https://github.com/iranzo/rhevm-utils/blob/master/rhev-vm-start.py >>> >>> which could do to the trick if run at host boot. >>> >>> I've also thought (but not tried) to mark a virtual machine as >>> "Highly Available" even if I have only one host (I mean, usually >>> HA only makes sense when you have two hosts). >>> >>> Marking a VM as H.A. would do the trick? >>> Any special reason why there isn't and standard way of marking >>> which vms should be auto-started at boot? >>> >>> Just wanted to hear your thoughts before filling an RFE. >>> >>> >>> Thank you. >>> >> what exactly is your use case? >> the one i'm familiar with is to tie the VM life cycle to a specific >> host, so a VM which is pinned to a specific host for a certain task >> (say, IDS), is always starting when the host starts, and will be >> automatically shutdown when host is moved to maintenance. >> so only relevant for VMs which are pinned to a host.
-- <http://www.btactic.com/>*Adrián Gibanel* I.T. Manager
+34 675 683 301 www.btactic.com <http://btactic.com/>
* Ens podeu seguir a/Nos podeis seguir en:
<http://www.facebook.com/pages/btactic/118651634826400?v=app_9953271133> i <http://twitter.com/btactic>*
Abans d´imprimir aquest missatge, pensa en el medi ambient. El medi ambient és cosa de tothom. / Antes de imprimir el mensaje piensa en el medio ambiente. El medio ambiente es cosa de todos.
AVIS: El contingut d'aquest missatge i els seus annexos és confidencial. Si no en sou el destinatari, us fem saber que està prohibit utilitzar-lo, divulgar-lo i/o copiar-lo sense tenir l'autorització corresponent. Si heu rebut aquest missatge per error, us agrairem que ho feu saber immediatament al remitent i que procediu a destruir el missatge.
AVISO: El contenido de este mensaje y de sus anexos es confidencial. Si no es el destinatario, les hacemos saber que está prohibido utilizarlo, divulgarlo y/o copiarlo sin tener la autorización correspondiente. Si han recibido este mensaje por error, les agradeceríamos que lo hagan saber inmediatamente al remitente y que procedan a destruir el mensaje.
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users