@greg_e I just stick it in the host because i had empty x8 pci slot and i need the GPU right now all those GPU are actually used up. 🙂

It works for my use which is very basic 2D autocad.

@heman

I had to use this when I didn't follow directions on my XCP-NG lab system.

Also a note to Freenas/Truenas users, make sure you "keep" a few old versions when you are upgrading things on your NAS, for exactly the same reasons. Yup, had to roll back on one of my production NAS this summer, nearly had a heart attack when stuff booted back up and none of the shares were accessible.

The only GPU I've tried to pass through has been an old Quadro 2000 card, and it seemed to work fine (though the old driver is a bit difficult on Win Server 2022). But the host also has a cheapo server GPU for XCP-NG to use for boot.

I mention Quadro because those didn't have the crippled firmware blocking them from pass through like the Geforce cards have/had. Kind of a dirty trick from nVidia!

Sorry I don't have any newer cards that I can test with, and I also only have Quadro cards here at all, "required" for some of our software.

What I did find out is that if you pass through a GPU, you can not migrate that VM to another host, even if that other host has the same model GPU installed. And with that my GPU pass though testing is complete.

@janvanhumbeek how long did you run Memtest for? Can you run it for the same length of time to see if it locks up. Check for BIOS updates. From the Logs you have C States errors so looks like Power management is not working you may need a different Kernel.

configure proper gpo for:

dcs clients

You need to answer the question: from where dc gets the time?

Try to boot in safe mode then.

Weird. Feel free to give more feedback if it happens again 👍

Confirming that @radioactiv's fix is all I needed too:

yum update -y

on my XCP-NG CLI did it.

You might get a free trial to play with it 🙂

@olivierlambert Thanks Master!

Regards from chile

This looks like it was a problem with the VDI's on a network shared storage.
Unpausing the VM's would "start" them but they never actually boot - no console would appear.

In the end, migrating all other VM off the host and then rebooting the host cleared whatever was causing these VMs to be stuck and we were able to delete them

We're currently trialing a new storage provider, so this is definitely something we'll be looking into more with their support.

@toby4213

It would show as many GPU as phisical procesors available.

Also what performance could I expect from one VM with a passed through GPU?
Regarding the use of GPU full , other performace depends of other resurces alocated for the VM. (disk, memory,...)

With passthrough does NVENC work in the VM?
YES

With the use of docker you can do as 20 nvenc per GPU... with K1,, we do 14 max with K2200 (1 GPU visible and passed thru to one machine)

Hard to tell without knowing all the details. Maybe there's other services to restart, I don't remember 🤷

For accessing a Windows VM from a remote Windows workstation using RDP multiple monitors can be used by selecting "Use all my monitors for remote session" checkbox on the display tab of the Remote Desktop Connection application on the Windows workstation. This works for me with 3 monitors.

You should probably ask OpenNebula community 🙂

What do you want to use/need with it exactly?

@danp Belatedly, many thanks

I never said THAT was impossible, as long the OS kernel started, you can use whatever drivers you like. I was just answering the fact PVHVM was a real mode since the start, and it's not. You can't have a PVHVM template, it doesn't make sense (unless you have already an OS installed).

That's all I said 🤷 You are moving the goalposts every time.

No worries 🙂

@olivierlambert Thanks. I tried that right now, booting with mitigations=off and saw no improvements unfortunately.

Before:

[09:06 VIRTUAL33 ~]# grep . /sys/devices/system/cpu/vulnerabilities/* /sys/devices/system/cpu/vulnerabilities/itlb_multihit:Not affected /sys/devices/system/cpu/vulnerabilities/l1tf:Not affected /sys/devices/system/cpu/vulnerabilities/mds:Not affected /sys/devices/system/cpu/vulnerabilities/meltdown:Not affected /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Vulnerable /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline, IBPB: conditional, STIBP: disabled, RSB filling /sys/devices/system/cpu/vulnerabilities/srbds:Not affected /sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Not affected

After:

[12:18 VIRTUAL33 ~]# grep . /sys/devices/system/cpu/vulnerabilities/* /sys/devices/system/cpu/vulnerabilities/l1tf:Not affected /sys/devices/system/cpu/vulnerabilities/meltdown:Not affected /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Vulnerable /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline, IBPB: conditional, STIBP: disabled, RSB filling

@olivierlambert

Just a update, I have moved from the Single Socket Server to the Dell R710 with 128GB of RAM successfully all VMs are working I have also updated to 8.2