@florent No problem, just thought it would be fun. Thanks for your work anyway!

Thanks for the heads-up and thanks for the help !

@acebmxer Yeah, I definitely believe this is not the latest version, but I was told it was kept like that for a reason. Can't quite remember what the reasoning is, as this is for another company who utilizes xoa. But, would running this command ' xe vm-reset-powerstate uuid=<VM_UUID> --force ' reboot the vm?

We do upgrade drivers, especially via alt, it's pretty safe (LTS doesn't mean frozen drivers). @stormi could confirm.

@DustyArmstrong thats super-strange, i actually have the same setup at home, 2 hp z240 machines running xcp-ng in a small pool. xcp1 is always up and running, xcp2 is powered down when I dont need it, everything important is running on xcp1, maybe that's the reason I don't run into these issues.

Hi @Bastien-Nollet, oh okay, thanks for clarifying!

@jmara Thank you for the input. All pods are running with caveats. Prior to executing the installation, I updated the image name to ghcr.io/vatesfr/xenorchestra-csi:edge in the manifests. After executing the install, I had to manually edit the image name in the DaemonSet, from ghcr.io/vatesfr/xenorchestra-csi-driver:edge to ghcr.io/vatesfr/xenorchestra-csi:edge. After editing the DaemonSet, the node pods restarted and transitioned to running. However, the controller pod was still attempting to pull this image: ghcr.io/vatesfr/xenorchestra-csi-driver:edge and never transitioned to running. To correct that, I edited the image name in the Deployment, from ghcr.io/vatesfr/xenorchestra-csi-driver:edge to ghcr.io/vatesfr/xenorchestra-csi:edge. Thus after editing the DaemonSet and Deployment, the pods transitioned to running. kgp -nkube-system | grep csi* csi-xenorchestra-controller-b5b695fb-ts4b9 3/3 Running 0 4m8s csi-xenorchestra-node-27qzg 3/3 Running 0 6m21s csi-xenorchestra-node-4bflf 3/3 Running 0 6m20s csi-xenorchestra-node-8tb5m 3/3 Running 0 6m20s csi-xenorchestra-node-t9m78 3/3 Running 0 6m20s

@AtaxyaNetwork Hi yes, Sorry I'm not super experienced in this area at all. I'm SSHd into the host and just ran dmesg -T in the root. [image: 1771509732474-0583e493-4d70-40b7-afc0-a88b0d9fd1a4-image.png]

@acebmxer There are older versions of the guest tools still available on Github.

Thank you all for information. I will try to virtualize GPU to Windows VMs.

@comdirect Use this command: (replace sda in the command below with the relevant device) cat /sys/block/sda/queue/scheduler The active scheduler will be enclosed in brackets. e.g. noop deadline [cfq] For multiple drives use: grep "" /sys/block/*/queue/scheduler

@acebmxer welcome to freedom.

Difficile de parler de « réalité » avec les benchmarks. Vérifiez aussi l'iodepth (qui dépend du type matériel que vous avez, sur du flash/NVMe vous pouvez monter à 128 ou 256), la latence entre en compte aussi bien sûr. Le bottleneck principal est le monothreading de tapdisk, si vous testez sur plusieurs VMs différentes la somme va monter de manière assez régulière.

@florent do the logs i provided help at all? or Idea why i am see this issue as well? I do not have a DR job just Delta backup and mirror backup.

Good afternoon, I have resolved the problem. Domo was trying to use the network Controller. Fixed it by using, /opt/xensource/libexec/xen-cmdline --set-dom0 "xen-pciback.hide=(0000:44:00.0)(0000:44:00.1)(0000:45:00.0)(0000:45:00.1)" reboot xl pci-assignable-list Xen Orchestra now allows PCI Networking Card to Pass-Through the VM. Regards

@Emmanuel-V said in Low end devices , share your experiences: I wonder to which extend we could lower dom0 memory, eventually reduce the set of features for this kind of usecases. I can definitely see a pool of machines (x86 or ARM) for industrial purpose where that could make sense, and that could be managed and update through XOA. Actually it’s not just the above, this technology (MicroVM) will also be of interest to hyperscalers down the road. As such I think that the handling of this should be an install time choice, as changing an already existing host to a MicroVM capable one can be messy. Doing it this way will enable a lot of capabilities for use with Xen Orchestra, in the handling of such MicroVMs. A hyperscaler already has this technology (Amazon AWS) with their Firecracker software technology.

Hi @kawreh Thank you for looking at my commit: https://github.com/vatesfr/xen-orchestra/pull/9507 If you are using sdn-controller, yes you will have to regenerate certificates (for XCP-ng on openssl-3), we are currently drafting a procedure to make it the easiest possible. rzr opened this pull request in vatesfr/xen-orchestra closed fix(sdn-controller): Support openssl-3 for ca/cert generation #9507

@magicker Thanks, I was also thinking it would be a good idea to monitor CPU temps just to make sure its nothing related to that. As I have a consumer motherboard I don't have IPMI to monitor. I believe I could install some linux temperature monitoring packages in the xcp-ng host, but I didn't dare to do that yet not wanting to risk breaking anything on the host. Or would you guys say it's in principle fine to install such temp monitoring tool on the host?

@EddieA Ok, good that your setup is now fully operational ! Let's sort this as a self-resolved problem then for now. Don't hesitate to ping us again if the issue comes back.