[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] how to start VMs in a particular order



"squidmobile@xxxxxxxxxxx" <squidmobile@xxxxxxxxxxx> writes:

>> In this case, the VM with the name server
>> needs to be up first, then the VM with the firewall, then the VM with
>> the NFS server and finally the rest of them in no particular order.
>
> hmmm.  can some of these come up in parallel?  does the firewall
> use ip addresses from the dns server, or does it hard code them?

All VMs start exim which apparently does DNS lookups in the process of
its configuration when started.

> does the firewall separate the nfs server from the dns server?

Yes, the name server is on a different VM (together with the mail server
the other VMs use as a smarthost).

> granted, the lack of dns affects the nfs clients, but wouldn't the
> nfs server (mostly) ignore dns until it finished booting and began
> nfs operations?

No --- or maybe.  When you put host names into exports, the NFS server
tries to resolve them.  IIRC it does that when reading exports, which it
has to before others can require its services (which one of the other
VMs does).

>> How do you find out whether a VM is fully up or not even within the very
>> same VM?
>
> well, dom0 can maintain a log of vm console output (i forget
> exactly where, but i think somewhere under /var/log/xen/console).
> tweak your vm startup scripts to echo something like "start the
> next vm" and let the dom0 auto script wait for the signal before xl
> create the next vm.  put a sleep 5 in the auto script to keep it
> from thrashing.  would some variant of this work for you?

I think enforcing a particular order in which the VMs are started and a
waiting period between starting each VM is the most reasonable approach
in my case.

It has the advantage of not needing to modify each VM to send a "ready"
message and not needing to somehow catch all the console output of each
VM.  That keeps things a lot simpler and less prone to mistakes and
errors.

The disadvantage is that it might take a bit longer than otherwise until
all VMs are up.  IMO, the simplicity outweighs the disadvantage,
especially since I can adjust the timers to minimise the waiting
periods.

I guess I could "encode" the waiting periods in the file names ... With
a name like '02-0300-VMx.cfg', I could make the starting script wait 300
seconds before it actually starts that VM, and it would start
'01-0000-VMz.cfg' before that, without waiting.  That would be plain and
simple.

Actually, the default xendomains script should do that ...


-- 
Knowledge is volatile and fluid.  Software is power.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.