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.

@irtaza9 I have the main characteristics of such a temple: Minimal install is the basis root fs: ext4 and minimum 10G disk IP: DHCP ssh login: cloud-user login, ssh public key only. If you are interested I can make it available for download.

@AtaxyaNetwork Glad i can help and give back to the community

@nathanael-h will

Ok, using a LDAP authenticated user is the problem. It works fine with a native XO account. Is there any way around this?

@wezke you are welcome. let us know if you find the explanation for the problem with the template

Thanx ! I will check out with your team at the start of the new year for subscription, maybe we will discuss about it. @olivierlambert said in User self-service creation automation: I don't think it's possible to treat that "automatically" as it's a very specific use case. However, it should be possible to script that using our API. I don't think so. It's definetivly not an hypervisor must-have feature, but cloud yes. If you are a cloud provider and providing compute to customers, you will want to build "plans" for subscritpion and assign it automatically when user create his account and choose is plan. It is the same thing here, instead of not having bilings and several plans. Have a nice Christmas !

@olivierlambert if that’s the case, great! I’m developing some modules for the xenorchestra terraform provider, and want to understand all the options.

Yes, we created the DevOps team so we'll have more bandwidth coming with it.

@bvivi57 Ah yes, good catch, I didn't think of that !