If it's only the XAPI that was damaged, you can restore metadata from your XO/Pool metadata backup. Alternatively, if you forgot to make metadata backup, you can introduce SR to find back all your previous disks (but you will lose the medata data with it).

@Andrew Thank you so much, I was not sure if there was a weird quirk between the generations that would cause them to be ejected from the current pool. That simplifies the rest of my upgrade then, first will be the CPU's, and then I will do memory next, just have to wait slightly due to my budget, but looking forward to the uplift for multi threaded. The single core uplift will just be a bonus on top, but I am trying to stretch out this platform for as long as I can get away with. Again thank you for the response much apprciated

@andyhhp Well, then I'm glad I spent $35 each on the 2683s while the company spent $125 each on the 2697s. Saved me $180 and it has all the same functionality but just a bit less speed.

@KPS I also patched Windows 2016 und 2022 to latest version. With xen guest tools. Both worked fine as well. We dont have a 2019 machine to test with.

@jjanvier check your disk empty space....

@Danp i did not have this notifcation is that limited to the pro version?

Hello everyone, XCP-NG 8.2.1 here. Recently, I encountered issues with SR network connectivity (10Gb iSCSI), which caused a few virtual machines (VMs) to stop and subsequently fail to start, displaying the well-known error message: FAILED_TO_START_EMULATOR. While restarting the toolstack or the host are proven solutions, I would like to suggest two additional approaches: If you have at least two hosts in the same pool, attempt to start the VM on another host. Create a snapshot of the VM and immediately revert to it. Then try to start the VM again. This should resolve the issue.

Thanks a lot for your feedback!

@andSmv thanks for coming back on this. Actually you are right it is a limit on Windows OS as per documentation here https://learn.microsoft.com/en-us/windows-server/get-started/editions-comparison-windows-server-2019?tabs=full-comparison. Should have checked this before I asked the question

@vahric-0 No, I believe that either should work well with 2019

@olivierlambert A little feedback regarding my problem that some may have in the future in the case of purchasing an external box which will be connected to an XCP-NG host. It turns out that the Sabrent brand box that I bought will not work with XCP-NG, there would be quite a few basic problems. To see if with a more recent kernel in the next XCP version this resolves the problem or not. I tried the bypass with a uas blacklist without success the box remains blacklisted : touch /etc/modprobe.d/blacklist-usb.conf echo "blacklist uas" > /etc/modprobe.d/blacklist-usb.conf reboot But none with an old box (5 storage spaces in USB3) which is not black listed. Subject on the site Kernel.org (Kernel 4.18.12) : https://bugzilla.kernel.org/show_bug.cgi?id=201421 https://lore.kernel.org/all/CA+icZUXHnc-Qd9NhwxFx3+LQakNTWmS_RRYsTAY8-gO8wc219Q@mail.gmail.com/ Amazon (user feedback with similar problems) : https://www.amazon.com/gp/customer-reviews/R1PSQWXUTUMLAD I will therefore keep this enclosure for another use with a machine having a more recent kernel (6.1) where this will not be an issue. I will test it with a version of CentOS 7 with a kernel version close to the current one to see if I encounter the same issues.

ls -la | grep "grid_t4" -r--r--r-- 1 root root 530 Mar 7 08:09 grid_t4-16a.conf -r--r--r-- 1 root root 556 Mar 7 08:09 grid_t4-16q.conf -r--r--r-- 1 root root 529 Mar 7 08:09 grid_t4-1a.conf -r--r--r-- 1 root root 529 Mar 7 08:09 grid_t4-1b4.conf -r--r--r-- 1 root root 529 Mar 7 08:09 grid_t4-1b.conf -r--r--r-- 1 root root 555 Mar 7 08:09 grid_t4-1q.conf -r--r--r-- 1 root root 528 Mar 7 08:09 grid_t4-2a.conf -r--r--r-- 1 root root 528 Mar 7 08:09 grid_t4-2b4.conf -r--r--r-- 1 root root 528 Mar 7 08:09 grid_t4-2b.conf -r--r--r-- 1 root root 554 Mar 7 08:09 grid_t4-2q.conf -r--r--r-- 1 root root 529 Mar 7 08:09 grid_t4-4a.conf -r--r--r-- 1 root root 555 Mar 7 08:09 grid_t4-4q.conf -r--r--r-- 1 root root 530 Mar 7 08:09 grid_t4-8a.conf -r--r--r-- 1 root root 556 Mar 7 08:09 grid_t4-8q.conf

It's a bit hard to tell with so little details Could you provide more context, the network bandwidth between XO, XCP-ng, your PC where you import the drives etc.

@Danp yes your correct .. however my source issues started again.. there is some issue using kubernetes, longhorn with mariadb operator in xcpng having a hard time tracking down the root cause

That's interesting though

@alpenliebeanj I know you resolved this a different way but what I did when migrating P2V from a bare metal debian system to xcpng is using clonezilla I transferred the image via the network to the VM which was booted to clonezilla as well. Then I changed the boot option to UEFI in advanced, pressed escape on startup and then proceeded to add a boot menu entry for grub of the Debian system. I would assume the process would have been similar in your case as well to resolve.

Okay then try CPU cap at 400