Ansible and XAPI first playbook (Ansible)

SethNY

I have been using ansible and community.general.xenserver_guest_powerstate to power on VMs in order, directly to the host.

I'm looking for a link or example of a "first Ansible playbook" to go to XAPI (the orchestrator built from sources) instead.

Example direct to host:

hosts: localhost
tasks:
- name: Power on opnsense
  community.general.xenserver_guest_powerstate:
  hostname: "{{ xenserver_hostname }}"
  username: "{{ xenserver_username }}"
  password: "{{ xenserver_password }}"
  name: opnsense
  state: powered-on
  delegate_to: localhost
  register: facts

Looking for example using XO instead.

bvitnik

@SethNY There are no Ansible modules for Xen Orchestra (XO) so there are no such examples. You could theoreticaly call Xen Orchestra REST API directly using Ansible url module but that is a stretch.

I think you are missunderstanding what XAPI is. It is an API that is used for management of XenServer and XCP-ng hosts and pools, including any object on them like VMs, networks, disks etc. It is feature full. Ansible modules use XAPI to manage hosts/pools regardless of them being XenServer (commercial solution by Citrix) or XCP-ng (free and open source solution). Both are supported and mostly have cross compatibility.

Xen Orchestra is a management tool that itself uses XAPI in the background to manage XenServer/XCP-ng hosts/pools

Now a question. What are you trying to accomplish by managing hosts/pools through Xen Orchestra instead of managing them directly using Ansible modules?

SethNY

@bvitnik Thanks for that feedback.

XO understands multiple hosts and should be able to see what host a VM is on.

Instead of using Ansible directly against individual hosts, I am looking about how to use Ansible to work with the management layer.

bvitnik

@SethNY said in Ansible and XAPI first playbook (Ansible):

@bvitnik Thanks for that feedback.

XO understands multiple hosts and should be able to see what host a VM is on.

Yes and no. VM names are not unique so there could be multiple VMs with same name on multiple hosts/pools. Even on a single host/pool there can be VMs with same name. VM UUIDs are unique but only inside a single host/pool. Theoreticaly, you could have multiple VMs with same name and same UUID if you have multiple independant hosts or pools. XO would not be able to distinguish them when searching.

Instead of using Ansible directly against individual hosts, I am looking about how to use Ansible to work with the management layer.

You can loop over your hosts in Ansible to find the host running the VMs. Unless the list of your hosts is constantly changing, this should be a single additional Ansible task. No more than that .

The way I handle it is to specify each VM to be in a particular group in Ansible inventory. Each group points to a specific pool. This is even before VM is provisioned. That way Ansible alway knows where the VM is.

olivierlambert

UUID collisions are very very very unlikely, even at scale.

SethNY

@olivierlambert and @bvitnik thank you for those thoughts.

I'm thinking at a larger scale than I need right now.

In the future I would like to be able to do things like: migrate all VMs matching <tag x> or name similar to host B (because it's a new host or because I'm taking down A for patching). Ansible is idempotent and perfect for things like that.

Move all large disks to my thin-provisioned SRs.

Move all powered down VM's disk storage to my NFS SR.

Move all VMs with "automatically power on" to host A.

Maybe someday.

bvitnik

@SethNY Unfortunately there is currently zero perceived interest in further development of Ansible support for XenServer/XCP-ng, from the user side I mean. Since module inception, there were only a few bug reports and one feature request (to support VM snapshotting), at least judging by GitHub issues. There are no Ansible forum discussions either. This pretty much killed my interest in developing new modules. If there were more interest among users, I could reconsider.

Ansible module development is h-a-r-d, especially if you want to support idempotency properly. Upstreaming the module to community.general collection is even harder because of strict rules about code quality and automated unit testing. For small and very specific tasks like VM migration in your examples I tend to write bash or Python scripts to do the job, either by calling them from Ansible or manually. Developing a module to do the same task would take much much more time.

On one side, Terraform is much more popular for VM management. Most people do not even consider using Ansible for doing the same. On the other side, XenServer/XCP-ng is way way less popular compared to all the other virtualization solution which is shame because it is technically quite capable. I blame Citrix for making a few very bad decisions:

Using ocaml for developing xapi daemon. It's a nice and powerful language but hard to digest by most people. This killed outside contributions even though it is open source. It also made a hard time for Citrix to find engineers for expanding their team.
Citrix failed to develop web based replacement for XenCenter. VMware did it right on time. Rest is history.

All this does not spell hope especially for large, enterprise users which can drive the development.

SethNY

@bvitnik Thank you for the great response. I have had great success with Terraform - great work.

I'm not touching ocaml myself. And yes, Citrix... they are still above VMware/Broadcom on my list. But SMH.

I keep promoting XCP-ng hoping some large companies take advantage of it. It's much more valuable to me than nautobot, for example.