@ruskofd is right. You should be able to use the cloud_network_config attribute to achieve this.

The following code is untested but should launch a vm with a static IP. Please see the xenorchestra_vm resource docs and the cloud-init networking v1 docs for more details.

resource "xenorchestra_vm" "static_ip_vm" {
....
  cloud_network_config = <<EOF
network:
version: 1
config:
  - type: physical
    name: eth0
    subnets:
      - type: static
        address: STATIC_IP/24
        gateway: GATEWAY_IP
        dns_nameservers:
          - 8.8.8.8
EOF
}

Let me know if you have any questions or issues using cloud_network_config,

As for the blog post, the VM would have been assigned an ip address via dhcp (assuming the guest OS had cloud-init installed which was true for the VM template in the blog post).

@fred974

I just saw that terraform had a free cloud account for less that 5 users and I was thinking of registering, will it work?

Terraform cloud would work if your XO deployment was publicly accessible. I highly advise against this because if your XO deployment were compromised an attacker has access to your entire infrastructure.

If you were to do this I would make sure all of your user's have strong passwords and if Hashicorp has documented public IPs that you only open your firewall to Hashicorp's Ips. It seems from this forum post that this is only available if you on the business tier.

If I run Terraform in a VM on xcp-ng, I don't need to open any port and use Terraform localy.

Yes running it on the xcp-ng host would work, however, keeping best practices in mind I would run it on a less privileged host (laptop with vpn access, development VM). If you have others collaborating on this terraform deployment, giving access to the xcp-ng host just to use terraform seems like a heavy hammer.

Is there a simple script I can run to see if I can access the Xen Orchestra API?

nmap will be able to tell you this.

nmap -sT -P0 -p 443 xo-domain

@fred974

I just saw that terraform had a free cloud account for less that 5 users and I was thinking of registering, will it work?

Terraform cloud would work if your XO deployment was publicly accessible. I highly advise against this because if your XO deployment were compromised an attacker has access to your entire infrastructure.

If you were to do this I would make sure all of your user's have strong passwords and if Hashicorp has documented public IPs that you only open your firewall to Hashicorp's Ips. It seems from this forum post that this is only available if you on the business tier.

If I run Terraform in a VM on xcp-ng, I don't need to open any port and use Terraform localy.

Yes running it on the xcp-ng host would work, however, keeping best practices in mind I would run it on a less privileged host (laptop with vpn access, development VM). If you have others collaborating on this terraform deployment, giving access to the xcp-ng host just to use terraform seems like a heavy hammer.

Is there a simple script I can run to see if I can access the Xen Orchestra API?

nmap will be able to tell you this.

nmap -sT -P0 -p 443 xo-domain

@itnok yea it appears the project uses the plugin api for Vagrant 1.x which may not work with Vagrant 2.x (the latest version) I'm not sure if the plugin api has changed significantly since I haven't written any plugins myself.

@ruskofd is right. You should be able to use the cloud_network_config attribute to achieve this.

The following code is untested but should launch a vm with a static IP. Please see the xenorchestra_vm resource docs and the cloud-init networking v1 docs for more details.

resource "xenorchestra_vm" "static_ip_vm" {
....
  cloud_network_config = <<EOF
network:
version: 1
config:
  - type: physical
    name: eth0
    subnets:
      - type: static
        address: STATIC_IP/24
        gateway: GATEWAY_IP
        dns_nameservers:
          - 8.8.8.8
EOF
}

Let me know if you have any questions or issues using cloud_network_config,

As for the blog post, the VM would have been assigned an ip address via dhcp (assuming the guest OS had cloud-init installed which was true for the VM template in the blog post).