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

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


  • To: xen-users@xxxxxxxxxxxxx
  • From: "J. Roeleveld" <joost@xxxxxxxxxxxx>
  • Date: Fri, 27 Jun 2014 21:58:03 +0200
  • Delivery-date: Fri, 27 Jun 2014 19:59:39 +0000
  • List-id: Xen user discussion <xen-users.lists.xen.org>

On Friday, June 27, 2014 03:19:03 AM lee wrote:
> "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 ...

You're not, I face exactly the same issue.
I have it on my todo list to write dependency-check scripts between the 
different xen-startup scripts that I use.

For these, I use different /etc/xen/auto/... folders for each stage.
The current "solution" is: I start each set manually, checking the xen-console 
logs to ensure it finished booting.

Final solution will either monitor the xen-console logs (which contain the 
textual output of the domU's) or test for the available of certain services by 
using scripting.
By ensuring the nagios stuff starts last in the sequence, I'd only need to 
test if "nrpe" is listening on the domU.

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