@probain No worries, im still learning/improving my ansible/terraform skills aswell

Starting from Other install media with BIOS (not uefi) is the only combo that is working with Terraform

UPDATE Now on XCP-ng 8.3 and XO from sources I had no problems with Windows 11. Had problem Ubuntu Noble Numbat 24.04 base template failing to boot from disk when cloned using Terraform. Changing the base template to "Other install media" resolved the issue, and the Terraform-cloned VMs work fine. EDIT: Also has problems with base template Windows Server 2025.

@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.

Can you share how you created the template? And copy here the template object from xo-cli or the rest api: xo-cli list-objects type=VM-template id=<your_template_id>?

What is the output of the following command: cloud-init schema --system

Again, XCP-ng and Xen Orchestra are really meant to work together: that’s by design. Our goal is to offer a unified stack with one consistent REST API to manage everything, across any number of pools. XO already handles a ton of things: auth (with oidc, SAML etc.), multi-pool aggregation, RBAC/ACLs, task tracking, templates, backups, live migrations, etc. By building on top of XO, we can focus on adding real value instead of re-implementing all that logic again in any 3rd party program we maintain in full open source and for free. And honestly, I don’t see any issue relying on XO: everything is fully open source, and all features are available for free from the sources, just like it’s always been. Nobody’s forcing you to use one or the other: if you’d rather build directly on XAPI, you absolutely can.

This approach isn’t entirely foolproof since I can’t use a wildcard, and I don’t know how many disks will be attached to the VM. For now, it will never exceed two disks, so I can explicitly include both in the ignore_changes statement. That’s an acceptable solution for us. Thanks for your support.

@sid It seems I have to get my hands dirty and take a deeper look into Terraform / OpenTofu. I am not shure how well the other folks at work partially will have fun working with commandline versus the easy to use XO web GUI. Tailoring down the CloudInit files used is not really the basic idea behind this. I was rather going the oposite way and install / configure the stuff we usually bake into our templates on the fly while generating the VM via CloudInit. Thanks a lot for all the responses !

Excellent news! Thanks for the feedback

I created a GitHub issue to track this feature request: https://github.com/vatesfr/terraform-provider-xenorchestra/issues/378 gCyrille created this issue in vatesfr/terraform-provider-xenorchestra open CPU topology (sockets/cores) for new VMs deployed via Terraform #378

Release v2.2.0 This new version introduces a new field, 'memory_min', for the VM resource and makes a slight change to the 'memory_max' field, which now sets both the dynamic and static maximum memory limits and providing better control of VM memory. What's Changed feat: Update TF provider to get VM memory improvements by @gCyrille in https://github.com/vatesfr/pulumi-xenorchestra/pull/420 Full Changelog: https://github.com/vatesfr/pulumi-xenorchestra/compare/v2.1.0...v2.2.0 JavaScript/TypeScript: @vates/pulumi-xenorchestra Python: pulumi-xenorchestra Go: github.com/vatesfr/pulumi-xenorchestra/sdk .NET: Pulumi.Xenorchestra gCyrille opened this pull request in vatesfr/pulumi-xenorchestra closed feat: Update TF provider to get VM memory improvements #420

Hi, thank you for the example! We will take a look. It could be a good idea to have a dedicated documentation/web page with usage examples of 'DevOps' tools

@deefdragon said in VM UUID via dmidecode does not match VM ID in xen-orchestra: Out of curiosity, I dumped the DMI into a bin and opened it up in a hex editor. I am seeing ASCII of the ID, but also a variant encoded in binary. In both cases, its formatted as 0b08f477-491a-a982-23c4-d224723624ea. I believe the ASCII version is the one that gets populated into the serial number as it comes after ASCII encoded versions of the 3 lines above it in the decode. In SMBIOS 2.8, the UUID is supposed to be encoded in little endian (i.e Microsoft GUID). Yet it is put as big endian instead. So when Linux generates the UUID string from the SMBIOS table, it is considered as little endian which causes this mismatch. SMBIOS 2.4 is supposed to be used (which appears to be using big endian UUIDs), but for some reason, something in XCP-ng UEFI supports forces it to be SMBIOS 2.8. So the binary UUID is the same, just that it is interpreted with a different endianness due to accidental format change.

@olivierlambert @nathanael-h @Team-DevOps Please let me know if you have answers for any of the flollowing questions: Why JSON-RPC over websocket regularly returns not expected result for calls and what could be done with it? examples: method xo.getAllObjects sometimes returns empty result, but following: jsonrpc method params ------- ------ ------ 2.0 all @{type=enter; items=} On retry - everything is fine and we have all data jsonrpc result ------- ------ 2.0 @{bbdb1ed0-4c86-24ec-...=;..... method vm.copy sometimes returns only task with name_label host.get_server_certificate and no task async.vm.copy. Meanwhile copy operation is started in XEN Orchestra, so we have to separately search for the task currently running in all objects and if it is not there anymore suggest that it completed successfully. Afterwards we need to check if vm was copied and appeared in all objects. That is really frustrating as we have no info about successfully completed tasks in XEN - records just removed as nothing happen. most likely this happens due to other tasks being popped up in tasks at the same time and websocket call recives not its own responce, is it possible to workaround? What is correct syntax for JSON to run job.create method? Are there any article with supported methods for JSON-RPC calls and examples to use them? Calling for "system.getMethodsInfo" I can see "job.create": { "description": "Creates a new job from description object", "params": { "job": { "type": "object", "properties": { "userId": { "type": "string", "optional": true }, "name": { "type": "string", "optional": true }, "timeout": { "type": "number", "optional": true }, "type": { "type": "string" }, "key": { "type": "string" }, "method": { "type": "string" }, "paramsVector": { "type": "object", "properties": { "type": { "type": "string" }, "items": { "type": "array", "items": { "type": "object" } } }, "optional": true } } } }, "permission": "admin" }, But it is unclear what values should I provide to paramsVector and looking into the job created manually (in web interface) with method job.getall I can see 2 jobs [ { "type": "call", "name": "copyvm", "key": "generictask", "method": "vm.copy", "paramsvector": { "type": "crossproduct", "items": [ { "type": "set", "values": [ { "name": "nevm", "vm": "GUID", "sr": "GUID" } ] } ] }, "userid": "GUID", "id": "GUID" }, { "method": "vm.copy", "key": "vm.copy", "name": "copyvmjob", "type": "call", "userid": "GUID", "id": "GUID" } ] How can I create similar job myself if it is not possible to find out why vm.copy does not return async.vm.copy task info?

@BSmithITGuy said in Ubuntu 22.04.5 custom template - additional steps missing from documentation: If you are trying to create an Ubuntu template and are having trouble on XCP-NG 8.3 (some or all probably applies to previous versions), keep reading. Very nice. Very thorough. This inspired me to share a relevant part of my cleanup script. Maybe it will be of some additional help to everyone: echo "Resetting machine ID..." > /etc/machine-id rm -f /etc/machine-info echo "Cleaning APT cache..." apt-get clean echo "Removing netplan configuration..." # Ubuntu < 24.04 rm -f /etc/netplan/00-installer-config.yaml # Ubuntu >= 24.04 rm -f /etc/netplan/50-cloud-init.yaml echo "Cloud-init cleanup..." if [[ -f "/etc/cloud/clean.d/99-installer" ]]; then chmod a-x /etc/cloud/clean.d/99-installer fi # Ubuntu < 24.04 rm -f /etc/cloud/cloud.cfg.d/99-installer.cfg /etc/cloud/cloud.cfg.d/subiquity-disable-cloudinit-networking.cfg # Ubuntu >= 24.04 rm -f /etc/cloud/cloud.cfg.d/90-installer-network.cfg if [[ -x "$(command -v cloud-init)" ]]; then cloud-init clean --logs --seed else echo " No cloud-init detected. Skipping cloud-init cleanup!" fi echo "Removing SSH host keys..." find /etc/ssh/ -type f -name 'ssh_host_*' -delete The code is self explanatory but here are some additional tips: It's nice to do cleanup of APT cache. This will free up some space but also force the user to update APT cache on first run after VM has been provisioned. If APT cache is not cleaned, it will grow stale over time inside a template and, after some time, package installation in new VMs will start to break. Doing apt update before any package installation is good practice but people tend to easily forget it. This will force them to do it. Ubuntu installer relies on some cloud-init config for some first boot setup which has to be removed if cloud-init is to be used once again for provisioning VMs. You correctly identified these files for removal but there is a difference in Ubuntu older than 24.04 and Ubuntu 24.04 and newer. The reason I do chmod a-x /etc/cloud/clean.d/99-installer is to prevent cloud-init from removing /etc/cloud/ds-identify.cfg when doing cloud-init clean (default behavior). Because I override the default /etc/cloud/ds-identify.cfg, I don't want cloud-init clean to remove it. I remove all the other files explicitly. Additional note, /etc/cloud/clean.d/99-installer should not be removed. It should just be chmoded because it is part of the cloud-init package and will reappear on cloud-init package update. It's better to use cloud-init clean --logs --seed command to clean any runtime cloud-init leftovers and logs instead of removing them explicitly like rm -rf /var/lib/cloud/instance. SSH host keys should be removed so that they can be regenerated on first boot of newly provisioned VM. If you don't do it, all your VMs will have same host keys which could be considered as security issue.

Question for @dinhngtu

Hello, I suggest you look also for Packer to build ready to use VM templates, with cloud-init, guest tools, and the softwares you'd need. There's a blog post for this https://xcp-ng.org/blog/2024/02/22/using-packer-with-xcp-ng/.

@Cyrille said in Kubernetes Recipe: @abreaux said in Kubernetes Recipe: Is there any way to get the cloud-init used in the Hub Kubernetes recipe? Looking to customize the deployment using Terraform and I want to make sure I include all the same tasks. What do you want to do actually? Do you want to "edit" a VM that has been deployed with the recipe (1), or do you want to deploy a new cluster that will copy the hub recipe (2)? In case of (1), you can find the cloud-init content inside the VM itself: /var/lib/cloud/instance/cloud-config.txt In the case of (2), the current version (5.105) of the k8s recipe is not really stable and is not intended to be used with Terraform. I can only recommend to find another solution (you can find some examples in the DevOps mega thread, like using Rancher). In the next release of XOA, we have updated the Kubernetes recipe to use MicroK8s, which provides a light, open-source, scalable and production-ready Kubernetes distribution. Actually, I didn't realize it was on the VM after deployment, so #1 is fine.