@aprado The onboard "serial port" is not a PCI device. You could try adding a USB serial port or a PCIe card with a serial port.

@PGibson You see the GUI on the VM console because that's the way you installed Debian. If you don't install a GUI or just disable it then you will have just a simple VGA text console. This might help.

@jgdub Are you using XCP 8.3 or 8.2.1?

@Mt_KEGan While my driver package uses the same name with an updated version, it is not an official XCP/Vates package. I have submitted an updated driver package to set the safer defaults. It's the same code with just different default settings.

@gduperrey Updates installed and running but I don't have 8.3 in production yet...

@gduperrey Installed and working on a HA pool and other hosts, no XOSTOR.

@FrankAtHome The server is a HP DL360 G8 Intel Xeon CPU E5-2680v2.

Same hardware/bios config as the other servers running XCP 8.2, so, nothing special setup. I'm not sure if it even has C5/C6 states available. It's an enterprise server, you don't want it to sleep.

Here's the output from a desktop HP Elitedesk 800 G3 Intel Core i7-7700 running XCP 8.3, again, nothing special setup. Now with more C-states!

# xenpm get-cpuidle-states 0
All C-states allowed

cpu id               : 0
total C-states       : 7
idle time(ms)        : 276484
C0                   : transition [              277556]
                       residency  [               16869 ms]
C1                   : transition [              197012]
                       residency  [                9993 ms]
C2                   : transition [               23581]
                       residency  [               11105 ms]
C3                   : transition [                2943]
                       residency  [                2094 ms]
C4                   : transition [                8525]
                       residency  [                8576 ms]
C5                   : transition [                5493]
                       residency  [               17883 ms]
C6                   : transition [               40001]
                       residency  [              224993 ms]
cc3                  : [                1946 ms]
cc6                  : [                7945 ms]
cc7                  : [              238808 ms]

@FrankAtHome Here's output on one of my XCP 8.3 servers that shows C0 to C4:

# xenpm get-cpuidle-states 0
All C-states allowed

cpu id               : 0
total C-states       : 5
idle time(ms)        : 1854395327
C0                   : transition [           827366196]
                       residency  [            26328742 ms]
C1                   : transition [           464493378]
                       residency  [            40172860 ms]
C2                   : transition [            97685021]
                       residency  [            43104018 ms]
C3                   : transition [            13728657]
                       residency  [            12613910 ms]
C4                   : transition [           251459140]
                       residency  [          1755416981 ms]
pc2                  : [           462155589 ms]
pc3                  : [            17985256 ms]
pc6                  : [           781427622 ms]
cc3                  : [            10502718 ms]
cc6                  : [          1685502286 ms]

@bleader I'll guess it's a VM guest process to process memory issue as the Xen patch is just for documentation of the issue.

The patch to Xen is simply a documentation update to clarify that an OS author
might not want to use a hypercall page.

@Double-e If you serial ports show up as a PCI or USB device then you can pass it to a VM. Most normal on-board serial ports can not be directly used in a VM.

Use lspci and lsusb to check your devices.

@dinhngtu It happened again to me.... Windows 10 22H2 on XCP 8.2.1...

Same issue as others. Windows reports a USB driver issue. Disabling/re-enabling the windows driver makes it work again.

To answer your question, Yes, reverting to a snapshot with memory keeps the problem of a failed USB/mouse.

@gudge25 ...forget about it... Mikrotik won't fix v6 and they have a proprietary OS, so you can't install normal stuff.

@abudef @olivierlambert @thomas-dkmt I agree. I read block the same way... how about disable or prevent. (French? empêcher)

@gudge25 @olivierlambert It works 100% correctly for me...

Step 1: download chr-7.16.2.ova
Step 2: Use XO and import chr-7.16.2.ova using defaults
Step 3: Start VM and watch it boot...

It boots and Management agent 6.6.80-71 detected as the it is included by Mikrotik.

@dinhngtu Just restarting the VM is good enough to restore console XO functions.

@olivierlambert I can't reproduce the problem on demand.... but I still hit it sometimes.

I'm on XCP 8.3 (updates, and test updates), XO source (current master db9c8) and windows (several versions) VM with XS 9.4.0-146 drivers. I have never seen this problem on an XCP 8.2 server. I don't think it's XO or my desktop as I use the same setup to manage all VMs on different hosts.

For me, I don't think it's the host LAN card as the host is fine (different LAN than VM), VM is fine, the video is fine, the keyboard is fine, it's just the XO console mouse that seems to get lost. Restarting the VM fixes the issue. Once I did close the browser window (not the whole browser) and the mouse worked again when I went back to it.

@knightjoel @olivierlambert Joel, thanks for working on OpenBSD. I see a patch was committed in November for this issue with XCP 8.3 (Xen 4.17) with 9pfs enabled.

I reinstalled OpenBSD 7.6 snapshot (Dec-26) and it's working now on XCP 8.3

Revision 1.100, Wed Nov 27 02:38:35 2024 UTC by jsg
Branch: MAIN
CVS Tags: HEAD
Changes since 1.99: +4 -5 lines

continue enumerating devices if a device is not matched

fixes xbf(4) and xnf(4) not attaching on XCP-ng 8.3/Xen 4.17
which has "device/9pfs/"

from Joel Knight

@LuisRiveraSig Since the device is not need for Xen Console or Dom0 then you can try a PCI pass-thru to the VM or use a USB device and pass it to the VM and just use the needed driver in the VM directly.

@LuisRiveraSig What are you trying to use the serial ports for?

• XCP console?
• Dom0 Serial port (ie. UPS monitor)?
• DomU/VM?

@plaidypus I am not 100% sure what the correct answer is for the default XCP configuration. I think the basic answer is: no. Xen/XCP does not care what cores it uses for your VM. So on average your performance will be a little worse than not crossing NUMA nodes but better than always interleaving NUMA nodes. Some systems will be better/worse than others.

Xen/XCP hypervisor does have a NUMA aware scheduler. There are two basic modes, one is CPU hard pinning where you specify which cores a VM (domain) uses. This would force the VM to use only the cores it is assigned. The other is to let Xen/XCP do its own work where it tries to schedule core use of a VM (domain) on a single CPU pool. The problem with this is the default config is to put all cores (and HT) in a single default pool. There are some options to try and enable best-effort NUMA assignment but I believe it is not set that way by default.

You can configure CPUs of a NUMA node into an individual pool (see below). A VM can be set for an affinity for a single pool (soft CPU pinning). This would keep most of the work on that single node as you want.

The links listed before to have good information about NUMA and CPU pinning. Below are some more:

Here is an older link about Xen on NUMA machines.
Here is a link about Xen CPU pools.
Here is a link about performance improvements on an AMD EPYC CPU (mostly related to AMD cache design).

There are also APIs in the guest tools to allow the VM to request resources based on NUMA nodes.

If you start hard limiting VMs where/how they can run you may break migration and HA for your XCP pool.