@olivierlambert Unfortunately they don't offer a guide, just a mention of it working. https://docs.citrix.com/en-us/citrix-hypervisor/graphics/hv-graphics-config.html Citrix Hypervisor supports Intel’s virtual GPU (GVT-g), a graphics acceleration solution that requires no additional hardware. It uses the Intel Iris Pro feature embedded in certain Intel processors, and a standard Intel GPU driver installed within the VM. However, they don't actually offer a guide on HOW to set this up besides offering some tips on how to setup BAR in the UEFI settings to change how many vGPU's it will support. I've enabled Above 4G Decoding, Re-size BAR Support and set the Aperture Size to 512MB but that doesn't seem to enable the vGPU options XCP-ng Center or XO. I'm assuming I need to enable it manually on the underlying OS before XCP-ng can see it. Note that the Intel GPU pass through is GVT-d NOT GVT-g. If you use GVT-d (AKA, just your regular PCIe pass through) obviously then I wouldn't be able to use the GPU for the the XCP-ng console on the machine itself. I'm comfortable on how to set that up but I really need the console available on the hypervisor for my use case. This video (in German) demonstrates setting it up in XCP-ng center. https://www.youtube.com/watch?v=FW9TPMrdTYc

@thault Yes. But there are more tools that can do IPMI than XAPI. Though, I must admit it is not on the top of my list of nice to have stuff for XCP-ng

@Kajetan321 No static memory would be 28G/28G 8/28 is dynamic memory

Hi. So I found an interesting thing on the Cloudmin side. I am able to change the grub config on the VM before I migrate, which then allows the boot to work on XCP-NG. How ever my main concern was if for some reason I need to roll back I won't be able to boot the VM up to the point where I can change the grub config. But in Cloudmin there is an option for me to change the device address that will then be able to match the grub config. Thank you again for all your assistance! I am very excited to pitch the migration path to my management this week!

Found it. Error is related to https://github.com/xapi-project/xen-api/issues/4141 Somehow, the PCIe bus address of the server's ASPEED VGA adapter changed. I got the new bus address with lspci and edited state.db accordingly. Works now. However, this seems to be a very strange bug. stormi created this issue in xapi-project/xen-api open XAPI failing to initialize after GPU removal? #4141

You are welcome. Weird issue indeed

Good news Also, now you are in HVM, which is a LOT better than PV for a lot of reasons (security, performance etc.)

@Marcsteven said in Troubleshooting System Interrupts issue: To resolve troubleshooting system interrupts errors, many methods can be executed. You can maybe disable sound effects. To do that, you can go to the taskbar and right-click the speaker icon. Then double-click your Default Device (speaker) > open Properties. Now tap the option of Enhancements and check the box which says ‘Disable all sound effects.’ Now press Ok to save the settings, and we will hope this will resolve the method. If it doesn't work then maybe you can update your PC's Bios by launching the Windows search > write CMD > run Command Prompt and then type these commands one after another > hit before you enter after each command systeminfo | findstr /I /c:bios wmic bios get manufacturer, smbiosbiosversion . Appreciate the ideas here, but most of it pertains to desktop machines not virtual guest instances (upgrading the PC BIOS is not really applicable for this unless it were occurring on ALL guests, for example).

@tekwendell xen carefully manages CPU power management to match VM load and vCPU count, I would not manually try to adjust things with xenpm in the meantime as it's likely you'll make things worse (don't try to outsmart xen power management unless you have a VERY specific use case). Xen is designed for paralleled workloads (more than a single VM), so there's many tunables for VMs that are set with this in mind (like CPU affinity). So by default I'm sure the CPU affinity for your single windows VM is still set somewhere in the "middle", so it's not going to be allowed to schedule the full CPU time versus what dom0 is also using. I'm not an expert in AMD/Epyc power management, but I believe it's pretty typical that CPU power/clock management boosts based on overall CPU load, and running a benchmark on only a single VM using something like 8 cores on a 64 core processor is not going to demand a lot CPU time, so I'm not surprised to see it's not boosting very far. Spin up 6 more of those VMs and benchmark them all at the same time, I wouldn't be surprised if you see it start boosting higher 475 cpu-z versus 501 bare metal is very good and indicates pretty clearly there's no issue here, you're getting 94% bare metal performance on windows under a large virtualization stack (historically the OS with the most overhead to virtualize). I would be very happy about this If you really want to dig further, ensure your bios power management is set to "OS-controlled", this will hand more control over turbo and c-states to the xen power manager and is what is recommended on AMD processors, and then you can use some commands listed here to check actual turbo status. But again, note that I won't be surprised if you can't get a 64-core processor to enter its highest turbo states when only stressing 1/10th of its cores: https://support.citrix.com/article/CTX200390/power-settings-in-citrix-hypervisor-cstates-turbo-and-cpu-frequency-scaling

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

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.

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