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

@sapcode Found a description here: https://linux.die.net/man/1/xm But no idea why it starts some CPUs in the pause state.... Will do some testing with C states and govenor performance.... STATES The State field lists 6 states for a Xen Domain, and which ones the current Domain is in. r - running      The domain is currently running on a CPU b - blocked     The domain is blocked, and not running or runnable. This can be caused because the domain is waiting on IO (a traditional wait state) or has gone to sleep because there was nothing else for it to do. p - paused       The domain has been paused, usually occurring through the administrator running xm pause. When in a paused state the domain will still consume allocated resources like memory, but will not be eligible for scheduling by the Xen hypervisor. s - shutdown   The guest has requested to be shutdown, rebooted or suspended, and the domain is in the process of being destroyed in response. c - crashed      The domain has crashed, which is always a violent ending. Usually this state can only occur if the domain has been configured not to restart on crash. See xmdomain.cfg for more info. d - dying         The domain is in process of dying, but hasn't completely shutdown or crashed.

Any thoughts on this topic? I noticed that Alpine from XO HUB didn't use irqbalance by default.

This means your XAPI is down for some reasons. Try a xe-toolstack-restart or check the logs as explained in our documentation: https://xcp-ng.org/docs/troubleshooting.html

@jmccoy555 got it. Thank you for being with me during this amazing journey

I am just curious in why this will not work on XCP-NG but will work on Proxmox when installing the drivers on the VM...

@olivierlambert said in Debian 10 cloud-init - VM encryption: You should ask the cloudinit community about this Thank you, I will do

So when you live migrate a VM, Xen will decrease memory dynamically to the minimum. If you didn't plan correctly dynamic min to a value that's OK for your system, you might have memory problems for your operating system (eg if you system can't survive with less than 4GiB RAM and the dynamic min is set to 3GiB, this will cause problems!). So planning is important. There's some edge cases also in migration when you have to tell Xen about memory management when you grow/reduce amount of RAM. But it works generally OK if you took care of dynamic min as I said.