@julien-f Thanks very much. Let me know when there is something to test.

@BenjiReis said in kubernetes recipe fails to deploy cluster: No the CIDR used by kubernetes is only used by Kubernetes to communicate between the master and the nodes. So each VM gets two VIFs? one private for k8s cluster traffic and another for "public", ingress, node ports etc ? If thats the case, i'm still not sure this will work for us, as our switches won't be able to route an arbitrary CIDR between XCP hosts if it doesn't belong to one of our networks The VMs will get an IP on your network for you to communicate with the VMs. By DHCP ?

Eg: xe pool-ha-enable heartbeat-sr-uuids=<SR-UUID> ha-config:timeout=90

@okynnor If you are using XOCE (from the sources) then you should be able to do this https://xen-orchestra.com/docs/metadata_backup.html, but if you are using XOA with free account, you won't have access to this feature. You can always clone the SAS drive to SSD and perform a reinstall if you can't get backup to work.

What does your cloud config logs show on the guest OS after boot? Can you see if it has made any attempt to inject the config? Only thing I can think of is that your cloud config might be wrong thus the cloud init service is refusing it. Have you tried to use an ubuntu image? I used official images of both debian 10 and ubuntu 18.04 and worked fine once I got rid of the pre-populated network config or inserted a real network config. I spent too long trying to figure out what was going on so let me know if there's anything else you need to know, it's super frustrating.

@kevstone122 If you don't have anything else plugged into the USB controller, you can try to passthrough the whole USB controller via PCI passthrough.

In other words, you must empty the host before add it to the primary pool, of course, you can migrate VM from one pool to another. And if your hw is not the same, but similar, you'll have an heterogeneous pool.

That's because UEFI is almost by default on HyperV since longer in XenServer/XCP-ng. When Windows 2012R2 was out, only BIOS was available on XenServer. So they put the template using UEFI. Again, with Xen Orchestra, you should have been able to enable UEFI with it.

@olivierlambert @stormi Having tests will be a great argument to become the new upstream Our situation is different from that of any linux distribution that wants to provide the tools (which we encourage any distro to do), since what we provide is a RPM that contains an ISO that itself contains DEBs, RPMs, and others. It's not something we can easily build in our build system, koji (though there may be a way to manage it). So we've get to automate that build process. This weekend I was able to finish the first tool I needed to help streamline the process of testing and building these tools. Its something I'm just calling PRT(Parallel Remote Terminal) for now. I currently have a number of testbeds in my cluster but testing manually on each is a huge pain. PRT is a tool that allows a user to define a group of remote hosts using a yaml file, then send the same command in parallel to each host. PRT returns the connection status, output, and errors on each host directly back to your machine. I hope you won't judge too hard on the quality of my code and docs because this was built in space of 48 hours lol. You can check it out here: https://github.com/JustinTimperio/prt I'll clean this up and improve it over the coming weeks but obviously, this is just tooling to help facilitate the actual work of improving these tools.

@Vinylrider your understanding is correct, delta retention is just how many deltas to keep before merging the oldest delta with the full. Full backup interval is the time between each new full back up for use in case of corrupted back up. To answer your question, yes it is recommended to have more than 1 full back up to fall back to in the event of corruption espcially of delta backups since delta backups rely on previous deltas meaning if one of your delta is corrupted, you'll loose all data from that point onward until another full backup is made, or worse your full backup could be corrupted (more likely because of the file size) then you loose the whole chain. And if your corrupted delta is merged with the full, you'll probably have a corrupted chain aswell.

FYI If you are looking for more info on the matter yourself ... ver: 20.2-2 of the cloud-init is still the one with the bug mentioned by @olivierlambert earlier: https://github.com/vatesfr/xen-orchestra/issues/4449 There is version 20.3 awaiting to be delivered but still awaiting to be packaged: https://tracker.debian.org/pkg/cloud-init flipsa created this issue in vatesfr/xen-orchestra open Cloud-init NoCloud block device has wrong dosfslabel --> cloud-init can't find datasource and exits #4449

Just tested, that was it. It was a 10 second fix to something I spent hours on. Well if anyone comes across this and is able to mount NFS storage pools successfully but cannot mount Backup Remotes, check that the Orchestra server itself (not the xcp-ng server) is on your NFS host ACL. Thanks to everyone who took the time to read this and especially to those that responded.

Sounds like a memory leak. It's hard to pinpoint in general. I would say that investigating on 8.2 as soon it's out would be probably a better thing to do (it will be an LTS). It will be out in beta soon

I opened an issue on this. Feel free to chime in with your thoughts -- https://github.com/vatesfr/xen-orchestra/issues/5284 Danp2 created this issue in vatesfr/xen-orchestra open Enhancement: Add ability to flag templates as hidden #5284

@Ascar said in Disk Usage for Control Domain on server 'abc.mydomain.com' has reached 92%.: If you see any deficiency in my plan please share your view. The main drawback I see is that you may have to reboot that VM from time to time, so the SR will become unresponsive and maybe hang some tasks until it's back. And when you reboot your hosts they will try to connect to a VM that may not be available yet. I would say definitely no for use of a VM as shared storage, but for an ISO SR that may be usable enough.

I will restart and use a systemrescuecd to run fsck

@tuxen Thanks for your reply, unfortunately I dont have the options ACPI - Display emulation. I use a Gigabyte Aorus X570 Pro for this server. IOMMU is enabled on the bord. With the Gigabyte B450 AORUS M I had zero issues, with booting in 'headless'.

@aghering the [NOBAK] option only excludes the transfer process, it will still try to make a snapshot of the disks. There are many possible causes for your UNIMPLEMENTED IN SM BACKEND issue, the most likely causes are probably storage related. If it is not a critical VM, you can try to disconnect the second storage disk and try again. If that doesn't work you might have to forget the SR and try (you can reattach it again, just need to remember your sr-uuid. Also, your /var/log/SMlog might reveal something.