Just to confirm. After copying new install.img to my PXE environment, unattended installation went smoothly with my answer file.

A milestone has been achieved . All of my modules have been merged upstream. I've updated the first post with new info.

That will most probably be all for Ansible 2.8. I'm keeping some improvements and possibly more modules for Ansible 2.9. Currently, I'm thinking about what other modules could be useful so I could implement them. Any suggestion or wish would be much appreciated.

@Ruskofff said in Ansible and XCP-ng:

Edit : I found the Ansible module you talking about @cheese (with the other topic talking about Ansible on XenServer). I could start from this point for the deployment of VM yes. Seems good for me !

This is the thread:

https://xcp-ng.org/forum/topic/159/deploy-vms-using-ansible

I'm the author of the module. The thread is a little outdated but I will update it ASAP. Feel free to ask me anything regarding the module.

Hi guys,

Sorry if this looks like shameless self promotion but for a few weeks now I've been working on Ansible module for managing XenServer/XCP-ng VMs - first of it's kind if I'm not mistaken. The module is in line with what Ansible offers for VMWare and there is a pull request to mainline it. What I would love is for anyone willing to help, and already familiar with Ansible, is to spare some time to test the module since the only way to test it is against real hardware. Of course, the module should not be tested in production environments.

UPDATE: 2019-03-01

Some of my Ansible modules have been merged upstream and are currently available in development version of Ansible. Ansible 2.8 will be the first official release to include these modules.

My work is currently centered around these three modules:

• xenserver_guest - upstreamed - used for deployment of new VMs from templates and reconfiguration of existing VMs.
• xenserver_guest_facts - upstreamed - used for getting VM facts (useful XenServer/XCP-ng VM params).
• xenserver_guest_powerstate - upstreamed - used for controlling VM power state (running/halted/suspended), graceful shutdown and reboot etc.

For anyone interested in using/testing these modules, upstreamed modules can be acquired by cloning Ansible repo from GitHub (or downloading the ZIP archive) and running Ansible from source. Instructions can be found here:

https://docs.ansible.com/ansible/devel/installation_guide/intro_installation.html#running-from-source

To use the modules, you will also need XenAPI.py from here:

https://raw.githubusercontent.com/xapi-project/xen-api/master/scripts/examples/python/XenAPI.py

Copy the file to your Python site-packages (e.g. /usr/lib/python2.7/site-packages/ on CentOS 7).

You can get module documentation by running this command:

$ ansible-doc <module_name>

or from official Ansible docs (upstreamed modules only):

• https://docs.ansible.com/ansible/devel/modules/xenserver_guest_module.html#xenserver-guest-module
• https://docs.ansible.com/ansible/devel/modules/xenserver_guest_facts_module.html#xenserver-guest-facts-module
• https://docs.ansible.com/ansible/devel/modules/xenserver_guest_powerstate_module.html#xenserver-guest-powerstate-module

CHANGELOG:

• Fixed a bug on XenServer 7.1 with Cumulative Update where a version could not be properly detected, causing an exception.

Thanks.

Just to confirm. After copying new install.img to my PXE environment, unattended installation went smoothly with my answer file.

@stormi So is install.img the only thing changed in ISO or is there some changes to rpm packages?

@Ced76 "register" is not a module parameter. It's Ansible task parameter. Take a look at Ansible documentation for registered variables:

https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#registering-variables

Basically what "register: deploy" does is that is says "define a variable called deploy and put a return value of the module in it". A return value of the module in this case are numerous VM facts you can find in "deploy.instance" (sub)variable. Registered variable is accessible in any subsequent task of the same play. Also "deploy" here is just a random name chosen. You can name your registered variables however you like.

@jedimarcus Network configuration (IP, subnet, gateway) only works for Windows guests because there is proper support for it in XenServer Guest Tools for Windows. There is no such support (as far as I know) in XenServer Guest Tools for *nix based systems. Unlike tools for Windows, tools for *nix based systems only contain a few xenstore tools and a daemon (xe-daemon) that collects OS metrics. There is no management agent.

My idea is to write a proper agent for *nix based systems at some point but it won't be any time soon. Maybe Citrix (or Vates ?) will implement one before I do.

For now, you can use custom based network configuration trough xenstore and custom scripts. It's described in Notes section of the module documentation.

A milestone has been achieved . All of my modules have been merged upstream. I've updated the first post with new info.

That will most probably be all for Ansible 2.8. I'm keeping some improvements and possibly more modules for Ansible 2.9. Currently, I'm thinking about what other modules could be useful so I could implement them. Any suggestion or wish would be much appreciated.

First post has been updated with new info. Another module has been merged upstream. Also some bugs were fixed.

@jthompson333 No problem. I'm following both forums so I'll try to respond same day.

@desnudopenguino Thanks .

I've updated the first post with some more info and clarified some confusing stuff.

@Ruskofff said in Ansible and XCP-ng:

I have a question about your module "xenserver_guest". Is it able to modify settings of the VM ? My main interest will be to mount the guest-tools.iso file to the VM. It's easy with the xe cli but I can't test it now that why I'm asking this.

Of course. Check out "cdrom" module parameter in the docs.

@Ruskofff I've updated the thread with new info regarding my modules.

The biggest advantage to using the modules instead of using xe tool or calling XAPI methods is that modules follow Ansible's idempotency principle. So you can run your Ansible playbooks multiple times without worrying that Ansible will do anything more times than expected.