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

@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

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

@acebmxer welcome to freedom.

@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

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.

@redakula said in Coral TPU PCI Passthrough: Frigate.nvr which is one of the popular uses for the Coral do not recommend it for new installs either. Frigate updated their recommendations because of the Google decision to sunset the device and because there are alternative options available to frigate for image inferencing. The coral is still supported though, and frigate is not the only use case or platform that can benefit from an accelerator. At the end of the day if you've already got the hardware, and it's efficient enough to run, then not using it is a waste or resources that could be allocated to other VMs.

@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