Okay sqo both disks are on VM_space_H1. Do a xe sr-param-list uuid=<SR UUID>, get the PBDs and for each do a xe pbd-param-list uuid=<PBD UUID> and paste the result 🙂

Ah nice!

Ideally, we'd like to avoid to use the complicated XAPI RRD + XML system. See https://xcp-ng.org/blog/2022/05/25/fetching-metrics-in-xen-why-the-method-matters/

Thanks a lot to bring this, I'll promote it!

PV mode is dead, HVM is faster anyway (with PV drivers).

Note this is not posted in the right category, since we talk mainly about XCP-ng and not Xen in a general distro 🙂

@gsrfan01 Not sure that was ever officially supported, though I did implement a direct connection to a VM on XenServer with better results than with the standard process. You're right, it may or may not work with much newer versions of XCP-NG/XS/CH.

@ganeshb Hi, think twice before going this path, with the xcp and the ubuntu hosting the containers seems to be a very good solution.
You can make good use of xcp features as backups snapshots, if something goes wrong, you can easily restore everything. You shouldn't be accessing dom0 if you aren't 100% sure of what u doing.

I havent used in prod but the coreos + the plugin looks the most native xen docker compatibility since xenserver 7.0 (I think), which would be more towards enterprises solutions.
CoreOS is RedHat based and a bit different than Debian based.

Between Large and small prod environments I'd say you are going fine.
If you want just for a home/small lab, you can try freenas which already comes with a web dashboard.

I hope it helps

@stevewest15 I would also increase your dom0 memory, 16 GB is already pretty much all being used and for migrating VMs, you need memory. Some of the resources are used for dealing with storage, whoch requires such resources. If the migration is slow, run iostat and see what resources are being used; there may be a storage bottleneck, as well.

@ember1205 it's not a matter of not being "well optimized" or xen arbitrarily removing support for old CPUs (we don't do that), it's a matter of the CPUs he's using being so old they're missing entire instruction sets that are required for proper virtualization. The Z800 systems you mention use xeons a full generation newer than the processors he's using, and were the first intel xeon generation to have proper full IOMMU/VT-d/etc instruction set support, so of course I'm sure they worked just great. The Z800 line is the same xeon generation as the 11th gen dells I mentioned, which is why I stated that is the oldest I would comfortably use - any generations older than these (like the poweredges zxcp is using) are missing core instruction sets xen relies upon.

Feel free to open a support ticket so we can see together if it makes sense, as I said it was written for some specific cases and it's not prime for broad use case.

@jaayb Amazing, TYSM!

@Darkbeldin Aaah, thanks for the clarification. Now I know....learned something today.

By the way, I've been so busy at work that I forgot my host has an iLO which I'd previously configured. I used it to gain console access and successfully rest the root credentials. I'm in and I have successfully reconnected XO to the host using the root credentials.

@AlexanderK

The server failed to handle your request, due to an internal error. The given message may give details useful for debugging the problem. message: xenopsd internal error: (Failure "Error from xenguesthelper: xenguest: xc_dom_build_image: [1] panic: xc_dom_boot.c:159: xc_dom_boot_domU_map: failed ")

hpe dl360p gen8. So its HPE problem?

xen-pciback.hide is precisely removing the devices from the Dom0.

However, xen-cmdline --delete-dom0 will actually REMOVE the parameters you entered in the grub configuration file.

In other words, xen-cmdline is a helper tool to edit Grub configuration file for Xen and Linux arguments (on boot).

As it's written, xen-cmdline --set-dom0 will actually set parameters for the dom0, and xen-cmdline --delete-dom0 will remove them.

@fohdeesha lol :-). ok.... good to now :). Next optimization by decoupling harddisks and fans.... and always be quite on the datacenter :).

I don't really remeber about the solution, but assume I deleted the old logfiles too. I did never observe the same failure again.

I'm also running xcp-ng on a Supermicro X11 with a XEON Silver 4210 CPU.

That would be interesting to get some pointers (like serial debug and so on). I wonder if there's already some resources for Xen Project somewhere 🤔

Good afternoon @olivierlambert !)
Most likely caused by the virtual machine itself. Because all the other VMs were fine) and the VMs are all on the same disks. According to the load and smart physical disks, everything was normal.
Also, when restarting the problematic virtual machine, the problem did not disappear. We didn't want to recover from backup, because it would take a lot of time and it was decided to move the virtual machine to another physical disk.(After that, the VM load problem disappeared)

@Andrew Good suggestion, might as well pick some up, thanks!