Fix VM name handling for virt commands when using vm_template

[Gabin-rte]

Using vm_template allows us to fully customize VM deployments, but it can lead to situations where the Ansible host name differs from the VM name in virsh. This discrepancy can cause issues with virt commands stop, undefine, and start in deployment role.

This update ensures that Seapath now correctly uses the VM name (as defined in the VM XML configuration) for these tasks, avoiding mismatches.

Use case: I encountered this issue with two hosts, DEBUG1 and DEBUG2, in my inventory. The VM names were dynamically generated using Jinja, like this: {{ inventory_hostname }}{{ supplier }}. As a result, I had to manually start my VMs due to the name mismatch between Ansible and virsh.

This fix resolves the issue by ensuring the correct VM name is always used for virt commands.

[eroussy]

I think it would be much simpler to add a field named "hostname" in the VM inventory, that would contain the name of the VM handled by virsh (that could be different of the name of the inventory_hostname)

It is already what is done for the physical machines

ansible/inventories/seapath_cluster_definition_example.yml

Line 11 in 2229fc3

hostname: "node1"

[Gabin-rte]

I am not talking about the hostname; I am referring to the VM name from the virsh point of view. These are two different things, and it seems risky to mix the two concepts.

[eroussy]

You're right
But then you can add another field in the inventory named "virsh_name" or something like that. It would contain the name of the VM used by virsh and would be used in the playbook.
Is it something that could solve your problem ?

[Gabin-rte]

This is something I initially considered. However, in my opinion, Seapath manages VMs in the simplest way possible: one XML and one VM. Adding more parameters than we currently have could expand Seapath’s scope to include VM configuration, which I believe is neither the right path nor the right place for it.

If you follow this approach, all playbooks and tasks related to VM hardening should be placed outside the main project, but that is not the focus of this PR.

In short: a supplier provides one XML and one VM qcow2 file to an integrator, who then deploys the VM using Seapath tools. Network configuration is defined in the xml with a dedicated tool.

That is my vision.

What specifically concerns you about this PR?

[dupremathieu]

This will only work for VM creation. I prefer using a third variable VMname and update the xml template to use this variable?

The other option is to change the VM name using vm_manager (vm_manager already does it on cluster but not on standalone).

[Gabin-rte]

I do not get it, as I said : it works with virsh "commands stop, undefine, and start in deployment role". I do not get why adding a variable is the solution regarding this issue : you already have this information.
Is there another playbook relative to the management of standalone VM that I am not aware of ? Because all I see is in this role and I can assure you it works perfectly without having to add one more variable.