Proxmox V8 & Windows2000 client, that needs to use COM1

[olebenny]

Hello
We are just setting up Proxmox V8 for Windows2000.
I have a Windows2000 client, that needs to use COM1 ( /dev/ttyS0 ). It will not work on COM2.
How do I disable 'serial console' and everything else, that could be using /dev/ttyS0 ??
As we don't have any source-code for the application, we can't change it to COM2

Best regards
Ole

 

[aaron]

If I understand correctly, you have a physical COM port that needs to be presented to the VM as COM1?

You can pass through physical devices as serial interface directly.

--serial[n] (/dev/.+|socket)
Create a serial device inside the VM (n is 0 to 3)

https://pve.proxmox.com/pve-docs/qm.1.html

Have you tried to set it like that and as what COM port is it recognized in the VM?
qm set VMID --serial0 /dev/ttyS0

 

[olebenny]

Hi Aaron

When I use 'qm set VMID (100) --serial /dev/ttyS0' and start my client, I can see on my VGA-console, that a lot of chars (as ******) are printed, until I stop the client, so some settings still link /dev/ttyS0 to 'console'.
Best regards
Ole

 

[aaron]

Correct me if I am wrong. The VM needs to see the serial interface as COM1. That then depends just on how many serial interfaces are configured AFAICT from my tests. To which physical serial interface they point to, is hidden from the VM.

So pointing it to ttyS1 for example should work as well. And the command should be
qm set 100 --serial0 /dev/ttyS1

Keep in mind the number behind --serial too. It needs to be run on the CLI, as the serial interfaces that can be created in the GUI are only useful if you want to set the display to serial as well.

If I add only one serial interface to the VM, it is seen as COM1, if I add another, I see a COM2.

Maybe show us the config of the VM? qm config 100 within [CODE][/CODE] tags for better readability

 

[olebenny]

Hi Aron
You are right. I spelled the device wrong, '/dev/tty0', where it should have been '/dev/ttyS0'.
I removed that serial port and added: qm set 100 --serial0 /dev/ttyS1 , but nothing comes out of the port.
I might have misunderstood 'passthrough'. I thought 'passthrough' meant that the VM was talking directly to the hardware.
So in this case, my Windows2000 would be using wrong port-address and irq, as it would be setup COM1 ( my driver ) but Proxmox would be offering /dev/ttyS1 == COM2.
Or do I need to setup something else for 'passthrough' ??

Best regards

Ole

 

[aaron]

The serial port will be added and emulated as its own device in the VM. The first serial port should show up as COM1, the second you configure as COM2 and so on. To which actual device or socket they connect to on the host is handled by Qemu passing the data through.

This is a bit different from passing through a PCI device directly.

What have you tried so far? If you connect another machin to the serial port, configure the serial port for the VM to use ttyS0 for example, do you see that they can communicate? IIRC there should still be Hyperterminal in Windows 2000 to use a serial port directly.

 

[olebenny]

Hi Aaron

After fixing the spelling of devicename (/dev/tty0 --> /dev/ttyS0) , it works with Microsoft standard driver for COM-port / 16550 - device.
Hyperterminal and also 'old' putty - version receives data and sends data from keyboard typing.

So if I install a miniPCIe-com-16550, it will be mapped directly to VM if for instance Proxmox se it as /dev/ttyS10 and I use 'qm set 100 --serial0 /dev/ttyS10' ??

Best regards

Ole

 

[aaron]

If that device is supported by the Linux kernel, then yes, this should work.

Out of curiosity, why would you need an additional serial port card? Multiple VMs that need direct access to a serial interface and the motherboard doesn't have enough? Keep in mind, that if one VM should get many serial connections, the limit for the --serialX config options is a max of 4, X being in the range of 0 to 3.

 

[olebenny]

Hi Aaron
This is a long story.
My customer has been using HP PC for many years with this application. The application is talking to PLC's via DANBUSS - protocol( made by Danish Danfoss company some 25-30 years ago ) through a RS232 to RS485 converter from Advantech (ADAM4520).
Then the HP PC went EOL, and the customer then used a 'box' PC from Sintrones with an external box, called RS2LAN, which communicated with PLCs on RS485 and the 'box' PC via ethernet/OPC.
In this setup, the box-pc runs Windows 7 Embeded Standard + VM-Ware Player V7 with the Windows2000 as a VM, talking to RS2LAN via 'ethernet'.
Now this RS2LAN is EOL, and nothing is a direct replacement, so we are back to the DANBUSS/RS232<-ADAM4520->RS485/PLCs.
The application is running on Windows2000, and when using DANBUSS via RS232, the COM-port driver is replaced with a DANBUSS WDM-driver + a DLL.
This has been tried out on Windows7/VM-Ware Player/Windows2000 using COM1, but VM-Ware Player does not handle the DANBUSS-WDM-driver - RTS - signaling, so data-direction on RS485 on ADAM4520 is not controlled. The application requests some data, then listens for some time to receive it.
We have an idea, that the box-pc's uart is not 100% 16550 compatible, as I have managed to start the application on a variant of the box-pc, where I could setup BIOS to simulate disk-interface as P-ATA, as I didn't succeed to install Windows2000 on S-ATA, as there are few AHCI for S-ATA available for Windows2000, and they don't work with the chipset in the box-pc. Running the Windows2000 in the box-pc with P-ATA showed very different RTS signaling, than on the HP PC, and the communication runs not good enough to be a success.
This is where a second miniPCIe for the box-pc comes in.
We want to try a 100% 16550 compatible uart, but I think it will fail.
The second reason for using Proxmox is the shield the Windows2000 + APP from the host-pc h/w for the future, but I am a novice regarding 'pass-through'. Never tried it before, but when somebody told about it, it sound like it could be the fix.

Best regards

Ole

 

[aaron]

Ah, the dance of trying to keep old software running. I don't envy you.

So yeah, to sum it up: if you use the --serialX parameter to pass through to a physical serial port, the virtualization (QEMU) will pass the data between the emulated serial port and the physical one. You have a higher abstraction with that.

The other option would be PCI passthrough of the additional serial port card. This will pass through the whole PCI device to the VM. This means that the VM needs to have drivers for it.

Therefore, I would try the first option as I assume it will be hard to get Windows 2000 drivers that work with it, unless these serial port cards are so generic, that the built-in drivers work. But then again, it has been a while since I had to deal with serial ports, especially with additional add in cards under Windows.

 

[olebenny]

Hi Aaron
Yes to all.
The main problem is, that I need to in stall my own driver on the serial port, and this works for the Tx/Rx data part, but the driver also controls RTS for setting direction on RS485, but the host does not handle this.
Regards
Ole

 

[olebenny]

Hi Aron
Is RTS supposed to be handled by host ??
Regards
Ole

 

[aaron]

sorry for the late response. Not really sure as I never had to go that deep, especially with a passed through serial port.
If it doesn't work, I would try to pass through the serial port card via PCI to the VM directly to have full control over it.

 

[olebenny]

Hi Aaron
No problem.
My main problem is, that COM-port has to be at I/O-address 0x3F8 ( COM1 ), and COM-port-driver in VM is Custom. No source available, so I can't change it.
Best regards
Ole