@ppikna97 Np, I was also using template_file originally but as its now deprecated there have been no builds released for M1 based Mac (leading/forcing me down the templatefile function route).

@ppikna97 Hi! How are you calling the templates in your VM resources? As you can see above from my examples I'm simply pulling both user data and network inline with the rest of my config e.g.

cloud_config = templatefile("cloud_config.tftpl", {
  hostname = "bw-lab"
  domain = var.network["domain"]
})
cloud_network_config = templatefile("cloud_network_config.tftpl", {
  ip = "10.1.55.37"
  netmask = var.network["netmask"]
  gateway = var.network["gateway"]
})

@ddelnano Sir, the only thing I could point out from that pull request is the block in your vm.md where you are templating the variables in a separate block.

"

# Template the cloudinit if needed
template = templatefile("cloud_config.tftpl", {
  hostname = "your-hostname"
  domain = "your.domain.com"
})

"
I have no where near enough experience with Terraform to tell if makes any practical difference, but I am able to redner the template inline with the rest of my VM resource definition. eg.

cloud_network_config = templatefile("cloud_network_config.tftpl", {
   ip = "10.1.55.37"
   netmask = var.network["netmask"]
   gateway = var.network["gateway"]
 })

Just a little tidier IMO, but again have no idea if the way you have done this is better practice etc.

Thanks

In case anyone comes here looking for an example (as it took me days of banging head against the proverbial wall to get this working with templatefile function):

cloud_config.tftpl

#cloud-config
hostname: ${hostname}
user: ops-user
ssh_authorized_keys:
  - OPS_USER_SSH_KEY
manage_etc_hosts: true
fqdn: ${hostname}.${domain}
package_upgrade: true
users:
 - default

cloud_network_config.tftpl

#cloud-config
version: 1
config:
    - type: physical
      name: eth0
      subnets:
      - type: static
        address: '${ip}'
        netmask: '255.255.255.0'
        gateway: '10.1.50.1'

vm.tf

resource "xenorchestra_vm" "unc-lab" {
......
 cloud_config = templatefile("cloud_config.tftpl", {
  hostname = "unc-lab"
  domain = "morris.lan"
})
cloud_network_config = templatefile("cloud_network_config.tftpl", {
  ip = "10.1.55.34"
})
.......

Thanks @ddelnano for your help!

@ddelnano Yeah, I only found it as template_file is deprecated apparently and as it hasn't seen any updates, I couldn't use the code you posted from my M1 Macbook

Anyways, thanks for the help!

Just stumbled upon this provider too which may offer a more streamlined approach, not that I am familiar enough with Terraform yet to say this for sure: https://github.com/hashicorp/terraform-provider-cloudinit

Thanks @ddelnano , that worked perfectly!

Appreciate the help!

Hi all,

New to the IaC world, trying to get Terraform to create a couple of VMs through Xen Orchestra but having a little trouble with cloud-init functionality. Network config gets parsed fine and the expected IP is applied.

However using the cloud-init user config that I usually use on the XO Web UI does not work. Within this cloud-init config, I'm using the name variable as shown below:

However it appears when this is used via Terraform, the variable does not get parsed and the cloud config drive ends up being generated and given to the VM as

#cloud-config
hostname: {name}

If anyone can help with this, would be much appreciated.

@olivierlambert Perfect, thanks again for your time!

@olivierlambert Thanks for the introduction to DPU, can't say I've heard of it before, but that certainly looks cool!

Any idea if Stub Domains are at all possible within a XAPI world (if so, any pointers to achieve this would be appreciated).

Also just wanna say you guys are awesome, XCP-ng + Xen Orchestra are incredible pieces of software, and the few times I've needed help here on the forum, @olivierlambert or one of your colleagues has jumped to the rescue in minutes!

Appreciate all the work you are doing, XCP-ng FTW!

Hi all,

I haven't seen any documentation on the matter, but I was wondering if either Stub Domains or Driver Domains are something that is feasibly achievable in an XCP-ng cluster environment?

I've been using both for a while now in Xen and love the idea of "separation of concerns" that DDs give and the added security of stubdoms.

For anyone not familiar, Stub Domains are small micro-code Xen domains that are responsible for the QEMU duties of a Xen guest, rather than dom0 being in charge of this. Driver Domains being similar, in that they take away control things of like networking away from dom0 and stuck them in a small PV guest.
https://wiki.xenproject.org/wiki/StubDom
https://wiki.xenproject.org/wiki/Driver_Domain

I am pretty new to XAPI so have no idea if this totally possible, and is a simple config line change somewhere or if I'm barking mad.
Either way, I'd love to know.

Thanks

@heman Not sure if it helps, but I had this exact problem in my pool. My shared storage was on another network that wasn't reachable by my XO host, but as soon as I added a second VIF to the XO host so that it could talk on the storage network, the issue went away and stats were available.

@olivierlambert Amazing. Thank you for your help sir!

@olivierlambert Thanks for your help Olivier, rebuilt my XO install and looks like I may have missed a dependency first time round, its now working.
Just wanted to check something with you, once the VM has booted once with the config drive attached, the config drive can then be disconnected and deleted, right?

@olivierlambert anddd what would ya know, it works with XOA! Man not the first time I am wishing I could afford to run XOA in the lab...

Any pointers as to where I can look at my build to try and rectify this?

@olivierlambert Hi Olivier, sure thing, I haven't seen any other stability issues with the build, but will give XOA a try now.

@m4xm0rris said in Blank CloudInit Drive from Xen Orchestra:

Hi all,

Been trying for a few days to get Xen Orchestra's cloud-init implementation to work with the Ubuntu 20.04 LTS Cloud image provided by Canonical to no success. This same image has worked previously with cloud-init under Proxmox.

Whatever I enter into either the User or Network config fields is not applied, even using the "SSH Key" method. I have tried this both while the VM is configured to look for only NoCloud as well as with al sources accepted.

Under inspection, I can see that the additional drive is seen in the VM (xvdb) but it appears to be completely empty. If I try to mount it, there is no vFAT FS detected.

Can anybody advise if there are packages that need to be installed in dom0 to accomodate creating the config drives correctly?

Thanks,
Maxwell

Quick amendment, this is with all the currently newest version of XCP-ng and XO from sources (built last week).

Hi all,

Been trying for a few days to get Xen Orchestra's cloud-init implementation to work with the Ubuntu 20.04 LTS Cloud image provided by Canonical to no success. This same image has worked previously with cloud-init under Proxmox.

Whatever I enter into either the User or Network config fields is not applied, even using the "SSH Key" method. I have tried this both while the VM is configured to look for only NoCloud as well as with al sources accepted.

Under inspection, I can see that the additional drive is seen in the VM (xvdb) but it appears to be completely empty. If I try to mount it, there is no vFAT FS detected.

Can anybody advise if there are packages that need to be installed in dom0 to accomodate creating the config drives correctly?

Thanks,
Maxwell