6:44 p.m.
Good morning!
Is there any way to configure VM start order? For example, I would like to make it so VM3
starts only after VM2 starts and VM2 starts only after VM1 starts. I know about
run/migrate priority, but it is the other scenario.
2:47 a.m.
You could ensure the VMs don't automatically start and use an Ansible
playbook to start the VMs in the order you like.
Something like:
---
- name: Playbook to start the VMs in the required order
hosts: localhost
tasks:
- name: Authenticate with RHV
ovirt.ovirt.ovirt_auth:
url: "{{ rhvm_url }}"
username: "{{ rhvm_username }}"
password: "{{ rhvm_password }}"
- name: "{{ vm }}: Connect to RHV and power the VM on"
ovirt.ovirt.ovirt_vm:
auth: "{{ ovirt_auth }}"
state: running
name: "{{ vm }}"
async: 180
poll: 0
loop:
- vm1
- vm2
- vm3
loop_control:
loop_var: vm
You'll need ansible installed (obviously) but also the ovirt.ovirt ansible
collection.
This is easily done with something like:
https_proxy=http://your_proxy:3128 ansible-galaxy collection install
ovirt.ovirt
Remove the https_proxy if its not required.
Hope that helps
On Mon, 15 Jul 2024 at 23:52, Sergei Panchenko <daemonff(a)gmail.com> wrote:
3:29 p.m.
Dear Colin!
Thank You for your answer.
However, as far as I understand, this is a manual method (the playbook must be run by an
administrator or user). And this will not prevent the administrator or user from starting
the virtual machines in a different order.
And a more complex question about the procedure for restarting the VM. In my case, it is
necessary to preserve the startup order across reboots: if VM2 was forced to restart (for
example, due to a host failure), then after starting VM2, it is necessary to restart VM3.
Is it possible?
12:06 a.m.
Hi
If you have a monitoring system then you should be able to monitor for the
specific condition of one or more of these VMs being down and that
monitoring system calling the playbook. We currently use Xymon and it has
been trivial to integrate Ansible Tower with Xymon to do exactly this kind
of thing.
The playbook I gave you merely informs oVirt (actually RHV in our case) of
the VM's required state. If the VM is already running Ovirt won't do
anything as the VM is already at desired state.
Hope that helps
On Tue, 16 Jul 2024 at 20:37, Sergei Panchenko <daemonff(a)gmail.com> wrote:
1:22 a.m.
I should have also said that not just admins can use the playbook. The
credentials to oVirt should be stored ansible-vault so that they are not
visible. Its a bit of a step up and more than a bit of a learning curve but
if you use Ansible Tower (or AWX) you can trivially allow an end user to
run that playbook without them ever knowing the credentials to oVirt. You
can do exactly the same thing with other products, for example Oracle
RDBMS. We use Ansible playbooks to allow first level support to extend
Oracle tablespaces, and shut/no shut ports on Cisco switches. This without
them ever knowing the credentials to the thing they are affecting.
I don't want to be Red Hat's marketing department but Ansible Tower
(nowadays Ansible Automation Platform) is the only product I've ever used
that lives up to the marketing hype.
On Wed, 17 Jul 2024 at 05:06, Colin Coe <colin.coe(a)gmail.com> wrote:
3:22 a.m.
This seems like it might be a good addition to a future version of oVirt. Add a
dependency option to a VM's configuration. And then maybe also a "Allowed to
automatically start dependency" checkbox.
292
days inactive
321
days old
6 comments
3 participants
participants (3)
-
Colin Coe -
Diggy Mc -
Sergei Panchenko