Keep in mind that the sevice (vm) is considered "up" the moment the
guest starts, ie not booted, so the delay would be minimal.
A more thorough approach to ordering guest start-up and delaying it
(either until some in-guest service is available and/or some time
interval after the previous guest has started would probably require
using your own script and the <script> resource. However, I think that
would mean that you also would need to roll your own solution relative
to live migration, etc since I believe rgmanager only supports live
migration of KVM guests as <vm> resources..?
// Thomas
On Jan 29, 2010, at 7:47, "Dirk H. Schulz" <dirk.schulz@xxxxxxxxxxxxx>
wrote:
Dirk H. Schulz schrieb:
Hi folks,
the VMs in my cluster are defined via <vm> containers which are not
inside <service> containers because the latter prevents live
migration (as far as I could find out).
Now when I start up the cluster, all VMs are started at once, which
I would like to prevent. Is there any way to define a startup
sequence or startup delay (like you can for the xendomains service)
without misusing dependencies?
Dirk
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
Just for the archive: I have an idea now.
I will try defining soft dependencies between the VMs (as I
understand soft is only regarded at startup), so I can have a
startup sequence which is even more than just a startup delay.
Any reasons why this should not work?
Dirk
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
