Hi,

This will be the case at some point, and it shouldn't be too difficult. We have the will to be able to provide a "cutting edge" version for people who want to play with fire 🙂

A big blog post is coming soon. I need to check with @matiasvl about trim passing via raw tapdisk datapath.

By whom? Again, this is more a question for OpenStack than us, since we are the layer under, not on top of it.

Stay tuned but work started 🙂

@olivierlambert sure. it's very long though, I grepped out the intel devices for a shorter version on the forum, and attached txt files with the full output.

I forgot there is also a gt 8800 present but i don't have the internal power cables for it (yet) and it looks like it needs them to even show up (some will work just die when they need more power). ill take it out next time I open it up.

the riser layout physically is this (from the back):
10gbe_8800_1050
6400__8400
6400

lspci | grep -vi intel 01:00.0 Ethernet controller: Broadcom Inc. and subsidiaries NetXtreme BCM5720 Gigabit Ethernet PCIe 01:00.1 Ethernet controller: Broadcom Inc. and subsidiaries NetXtreme BCM5720 Gigabit Ethernet PCIe 02:00.0 Ethernet controller: Broadcom Inc. and subsidiaries NetXtreme BCM5720 Gigabit Ethernet PCIe 02:00.1 Ethernet controller: Broadcom Inc. and subsidiaries NetXtreme BCM5720 Gigabit Ethernet PCIe 03:00.0 RAID bus controller: Broadcom / LSI MegaRAID SAS-3 3108 [Invader] (rev 02) 04:00.0 VGA compatible controller: NVIDIA Corporation GP107 [GeForce GTX 1050] (rev a1) 04:00.1 Audio device: NVIDIA Corporation GP107GL High Definition Audio Controller (rev a1) 06:00.0 VGA compatible controller: NVIDIA Corporation G86 [GeForce 8400 GS] (rev a1) 08:00.0 PCI bridge: Renesas Technology Corp. SH7758 PCIe Switch [PS] 09:00.0 PCI bridge: Renesas Technology Corp. SH7758 PCIe Switch [PS] 0a:00.0 PCI bridge: Renesas Technology Corp. SH7758 PCIe-PCI Bridge [PPB] 0b:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. G200eR2 (rev 01) 81:00.0 Ethernet controller: Mellanox Technologies MT26448 [ConnectX EN 10GigE, PCIe 2.0 5GT/s] (rev b0) 83:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Upstream Port of PCI Express Switch (rev c7) 84:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Downstream Port of PCI Express Switch 85:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Device 743f (rev c7) 85:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Navi 21 HDMI Audio [Radeon RX 6800/6800 XT / 6900 XT] 86:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Upstream Port of PCI Express Switch (rev c7) 87:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Downstream Port of PCI Express Switch 88:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Device 743f (rev c7) 88:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Navi 21 HDMI Audio [Radeon RX 6800/6800 XT / 6900 XT] lspci -tv | grep -vi intel +-[0000:80]-+-01.0-[81]----00.0 Mellanox Technologies MT26448 [ConnectX EN 10GigE, PCIe 2.0 5GT/s] | +-02.0-[82]-- | +-03.0-[83-85]----00.0-[84-85]----00.0-[85]--+-00.0 Advanced Micro Devices, Inc. [AMD/ATI] Device 743f | | \-00.1 Advanced Micro Devices, Inc. [AMD/ATI] Navi 21 HDMI Audio [Radeon RX 6800/6800 XT / 6900 XT] | +-03.2-[86-88]----00.0-[87-88]----00.0-[88]--+-00.0 Advanced Micro Devices, Inc. [AMD/ATI] Device 743f | | \-00.1 Advanced Micro Devices, Inc. [AMD/ATI] Navi 21 HDMI Audio [Radeon RX 6800/6800 XT / 6900 XT] +-01.0-[03]----00.0 Broadcom / LSI MegaRAID SAS-3 3108 [Invader] +-02.0-[04]--+-00.0 NVIDIA Corporation GP107 [GeForce GTX 1050] | \-00.1 NVIDIA Corporation GP107GL High Definition Audio Controller +-02.2-[05]-- +-03.0-[02]--+-00.0 Broadcom Inc. and subsidiaries NetXtreme BCM5720 Gigabit Ethernet PCIe | \-00.1 Broadcom Inc. and subsidiaries NetXtreme BCM5720 Gigabit Ethernet PCIe +-03.1-[01]--+-00.0 Broadcom Inc. and subsidiaries NetXtreme BCM5720 Gigabit Ethernet PCIe | \-00.1 Broadcom Inc. and subsidiaries NetXtreme BCM5720 Gigabit Ethernet PCIe +-03.2-[06]----00.0 NVIDIA Corporation G86 [GeForce 8400 GS] +-1c.0-[07]-- +-1c.7-[08-0c]----00.0-[09-0c]----00.0-[0a-0b]----00.0-[0b]----00.0 Matrox Electronics Systems Ltd. G200eR2

r730 lspci.txt
r730 lspci -vt.txt

Guys, thanks a lot for the replies! Despite that, xcp-ng is a fantastic solution and has been helping me a lot since the last year!

@fohdeesha Very interesting, thanks for the info! I did a double-take at the notion that wireless APs rely on the MAC address for authenticity... that's what the session key is for! But then I realised that the AP needs to be able to map IP/MAC address to session key for incoming packets, so it makes sense; we'd need one session per MAC address.

Welp, I guess it's cable-running time...

I do wonder, though: could the hypervisor act as the gateway for a subnet containing the guests, so that only the hypervisor is using the wireless connection? I don't know how challenging that would be to implement in XCP-ng, but I expect there'd be security implications, and one would still need a router that allows you to manually configure routes. Although I don't think I've ever come across a residential router/gateway that doesn't allow that, I haven't messed around with them, and I expect the ISP would just remotely reset custom routes after a restart, which would be a nuisance.

Hi,

Short term: no. Longer term when we have SMAPIv3: very likely, yes, at least as a community driver.

What about perfs? Can you describe more your setup and config?

@olivierlambert Awesome! That worked, thank you so much!

Update candidate available to fix certificate download: https://xcp-ng.org/forum/post/49373

Update candidate available to fix certificate download: https://xcp-ng.org/forum/post/49373

Cause problem is there anyway as a conflict of multiple Installations and / or Windows updates. There is a Solution if you dont have snapshop or backup of vm.

Start VM to recovery mode, select commandline. Remove all xcp related drivers with dism.

https://docs.microsoft.com/de-de/windows-hardware/manufacture/desktop/add-and-remove-drivers-to-an-offline-windows-image?view=windows-11

https://xenbits.xen.org/pvdrivers/win/8.2.2/

(use anytoiso to convert xeniface.tar, xenbus.tar, xenvif.tar, xennet.tar, xenvbd.tar and upload iso-Files to xen iso repository)

Load iso as CD/DVD device with contents of drivers tar files and reinstall the drivers manually by dism.

If you are fast, in 5mins Windows is starting as before.

Only when we'll have a more recent kernel in Dom0 🙂 But this will come at some point.

Sadly, it's not that simple. Allowing to change the partition layout will add probably a lot of complexity to maintain. However, we are not against a contribution, then we could judge the risk on getting it upstream or not 🙂

Sure, let me come back to you this week!

@cyoung_mi It's a XCP Xen/Kernel code issue... So if that can be fixed then yes.

@Andrew Let's start with igc.

Install git-lfs if not done already, fork and clone https://github.com/xcp-ng-rpms/igc-module/ and then create a PR against the 8.2 branch, based on the existing spec file.

@TheFrisianClause

From my experiments using a GTX1080ti you'll have to follow the instructions for generic pcie-passthrough to the letter, which mostly means that the passthrough needs to be done on both sides, on the Dom0 for relinquishing device control and for the DomU to pick up the device (section 5). Perhaps now that the restrictions from Nvidia have gone, Vates will kindly include some GUI support for those operations in XOA.

Note, that if your dGPU has multiple devices (e.g. my GTX 1080ti also has a USB-C controller on-board), both entries need to be added in a single 'xe vm-param-set' statement, otherwise only the latter device (USB in my case) will wind up in the VM.... (yeah, at least 30 minutes of puzzling on that one)

Of course, if the dGPU is your console device, it means flying blind afterwards, but I'm getting used to that with all the recent iGPUs as well (then again, I have some DisplayLink hardware that's currently unused and EL7/8 drivers for those have popped up recently...)

Thankfully the dreaded error 43 issues have gone away with the more recent Nvidia drivers, sadly Kepler support has been retired (got a lot of those still around), so you may want to preserve the latest CUDA 11.4 release as one that offers both, but for Maxwell you should still be fine.

Before trying to diagnose with the Nvidia drivers, you should be able to see the device transition via lspci on both sides, Dom0 and DomU.

@rajaa-b no problem

@jedimarcus true, but as this is the development part of the forum, I'm more coming from a "Nice to have" request.

The obvious solution is multiple orchestra servers 😉