Subcategories

• Management

  VMs, hosts, pools, networks and all other usual management tasks.
  359 Topics

  3k Posts

  L

  @kagbasi-ngc hello, sorry but I didn't manage to see your GIF, it didn't work on my side. Could you make some screenshot? I am asking XO Team.
• Advanced features

  ACLs, Self-service, Cloud-init, Load balancing...
  88 Topics

  760 Posts

  N

  @blackliner said in Sdn controller and physical network: @nikade How do you "pair" the XCP-ng SDN with your routing setup? You cant/dont, you'll have to setup each private network on the vyos router and then have the vm private network routed through it manually. For example if you have private network 1 with subnet 192.168.1.0/24 you'd have to add this network to the vyos router and assign 192.168.1.1/24 on the router. Then set 192.168.1.1 as default gateway in your vm's which uses this network. Then you'll setup ospf or bgp on the vyos router manually with your upstream border/core-router or firewall. If the subnet is a private subnet you'll need to setup NAT as well somewhere before it reaches internet to NAT traffic from 192.168.1.0/24.
• Backup

  All XO backup features: full and incremental, replication, mirrors...
  364 Topics

  4k Posts

  I

  @RobWhalley That worked for me as well. I created a new XenOrchestra VM with commit 3c543. Enabling and disabling NBD on the backup job did the trick. Thank you and everyone else for your efforts and digging into the matter. Regards Marc
• REST API

  Everything related to Xen Orchestra's REST API
  63 Topics

  486 Posts

  O

  This page is being improved as we speak It shouldn't be in "Future improvements" because it's here
• Infrastructure as Code

  Terraform, Packer or any tool to do IaC
  33 Topics

  308 Posts

  B

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