[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:

> 26 jun 2014
>
> greetings,
>
>> how would I make it so that VMs which are started automatically are
>> being started in a particular order?
>
> well, i have something that (sort of) works for me.  i create my
> vm.cfg files in a directory of my choosing and ln -s from that
> directory to etc/xen/auto.  i rename the symbolic links to look
> like this:
>   01.vm-name.cfg
>   02.vm-name.cfg
>   03.vm-name.cfg
>   ...

Yes, I though of numbering them --- haven't tried yet, though.

Is this a feature, or did you happen to create the links in the desired
order?  I see both possibilities, i. e. sorting the directory entries as
a feature, or start the VMs in the order the files/links have been
created/are found as directory entries.

> when i reboot my system, the vm's come up in the proper sequence.
> however, xen starts them at its pace and NOT when the previous vm
> is ready for transactions.

Yes, starting them one after another without waiting for them to be up
won't make a difference.  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.

> i suppose you could modify this with a sleep 5 (or whatever) between
> each vm.

A timer would do, but give the timer 5 minutes to make sure --- or at
least 3 --- and I'd be looking at at least 9--15 minutes before the VMs
are all up.  It won't matter much if the server didn't crash once a day,
but if it didn't, I wouldn't even really need a particular order.

> or maybe you could arrange some kind of signal from each vm to signal
> starting the next vm.

How do you find out whether a VM is fully up or not even within the very
same VM?  I've put a 5 minute sleep into the script that starts chronyd
because of dependencies (and still had to change to running the "master"
chronyd on dom0), and that doesn't delay starting everything else.

With this delay for chrony, I might have to assume that it takes more
than 5 minutes before a VM is fully up.  Let's say 7 --- and in that
case, there won't be a difference between using a timer in dom0 and
somehow sending a signal from a domU: Only a waiting time of 21 minutes,
which would kinda suck ...

Alternatively, I could go by what services are available.  For example,
chronyd doesn't need to be running for the NFS server to function, and
the name server doesn't have to either because I put IPs into exports
because otherwise it won't work unless the name server is up before the
NFS server, which it never was (unless perhaps I'd have put another 5
minute delay for the NFS server, ending up creating a long chain of
dependencies across all the VMs, which seems a bad idea).  But how do
you find out what services are already available?

The way it is now, rebooting the server takes, I don't know, like 10--15
minutes or so before everything is working again, plus the time it takes
to shut everything down.  That is a rather long time, and it's longer
than it should be because the VMs don't come back in the right order.

Hmm, I can't be the only one encountering this problem ...


-- 
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®.