How can I work with a VMware serial port?

Networking
1

I’m trying to use a virtual serial port in VMware for logging and remote console access, but I’m not sure what the best setup is. I’ve seen options for piping to a file, a named pipe, or a physical serial port, and I’m confused about which to choose and how to configure them correctly. Could someone explain the available VMware serial port options and share recommended configurations or examples for common use cases like debugging or console redirection?

2

For VMware serial ports you basically have three real-world use cases: logging output, interactive console, and talking to some external device. The “best” setup depends on which one you care about most.

1. For simple logging from the VM

Use “Output to file”:

  1. Edit VM settings
  2. Add Hardware → Serial Port
  3. “Use output file” and point it to a log file on the host
  4. Tick “Yield CPU on poll” if the guest likes to hammer the port

This is dead simple for kernel logs, boot loader output, panic traces, etc. You just tail the file on the host. Downsides: no interactive console, only output.

2. For remote console / bidirectional access

Use a named pipe and then attach whatever terminal you like.

On Windows host:

  • In VMware: set serial port to “Use named pipe”
  • Pipe name: \\.\pipe\vmserial1
  • One side “This end is the server” and the other “The other end is an application”
  • On the host, use PuTTY or similar, set “Connection type: Serial”, and put \\.\pipe\vmserial1 as the serial line with a dummy speed (VMware does not really care)

On Linux host:

  • Use “Use named pipe” and give it something like /tmp/vm-tty1
  • Then run socat or screen to connect:
    socat -,raw,echo=0 UNIX-CONNECT:/tmp/vm-tty1

This is the go to method for an interactive serial console.

3. For talking to a physical serial device

If your host actually has a COM port or a USB serial adapter:

  • Set serial port to “Use physical serial port” and choose COM1 / ttyS0 / ttyUSB0
  • This lets the VM see it as a real serial interface
  • Watch out for contention. Do not let the host and the guest fight over the same port at the same time.

If your device is on another machine or you want to share it:

  • Use a serial over IP solution. This is where Serial to Ethernet Connector comes in handy.
  • Install on the machine that has the real serial device. It exposes that serial port over TCP/IP.
  • Inside the VMware host or even inside the guest, use it to create a virtual COM port that maps to that remote one.
  • The VM then thinks it is talking to a local serial port, but traffic actually goes over the network. This is way more flexible than dragging cables around.

4. When you want the VM serial to live “on the network”

You can combine the named pipe with a TCP relay:

# Linux host example
socat TCP-LISTEN:5000,reuseaddr,fork UNIX-CONNECT:/tmp/vm-tty1

Now anything that connects to host:5000 can talk to the VM console. Handy for remote debugging or headless servers.

5. Clean way to learn it all in one place

If you want a single practical vmware serial port guide that walks through setups like logging, remote consoles, and network serial redirection, this page is solid:
Step by step VMware virtual serial port setup

TLDR setup recommendation:

  • Only want logs: “Output to file”
  • Want a proper console from host: “Named pipe” plus PuTTY or socat
  • Need hardware or remote device: “Physical serial port” plus Serial to Ethernet Connector if the device is on another box or needs to be shared over the network.
37 Likes
3

If you’re mainly torn between “file vs named pipe vs physical port,” think of it less as which is best and more as which is best for the workflow you want.

@andarilhonoturno already covered the basic wiring pretty nicely, so I’ll just fill in the gaps and disagree a bit where it matters.

1. Logging vs interactive: don’t mix them if you care about reliability

You can try to use a named pipe both for logging and interactive use, but in practice it’s annoying. For pure logging, I actually prefer:

  • Serial port set to “Use named pipe”
  • Then on the host run something like:
    socat -u UNIX-LISTEN:/tmp/vm-tty1,fork FILE:vm-serial.log,append

This way you can:

  • Rotate logs easily
  • Add timestamping with another layer (e.g. multilog, systemd-cat, or ts from moreutils)
  • Keep the option to attach interactively in another process

So instead of “Output to file” in VMware, I’d argue a named pipe plus logging tool is more flexible if you live in a Unix-ish world. VMware’s direct file logging is dead simple but pretty dumb: no timestamps, no rotation, and sometimes it buffers in confusing ways.

2. Remote console: named pipe is fine, but make it network-aware from day one

Where I partially disagree with the usual advice (including @andarilhonoturno’s) is stopping at “pipe + PuTTY/socat.” That’s fine if you only ever connect locally, but serial consoles shine when:

  • The VM is headless
  • You want to debug early boot from another box
  • Multiple people might need access

A cleaner approach:

  1. VMware serial port → named pipe
  2. Host service (e.g. socat or ser2net) → expose that pipe as TCP

Example with ser2net on Linux host:

/etc/ser2net.conf:

7001:raw:0:/tmp/vm-tty1:115200 8DATABITS NONE 1STOPBIT

Now anyone can do:

telnet host 7001

or use any serial-over-TCP capable tool. That scales way better than “PuTTY into a pipe on the single host.”

3. Physical serial ports: be paranoid about ownership

“Use physical serial port” looks tempting, but it has two classic footguns:

  1. Host vs guest contention
    VMware does not magically arbitrate. If some service on the host grabs /dev/ttyS0 or COM1, your VM gets weird flakiness. Disable getty / Windows services on that port first.

  2. USB serial dongles moving around
    On Linux, /dev/ttyUSB0 today might be /dev/ttyUSB1 tomorrow. Use udev rules to bind a persistent name, e.g. /dev/serial/mydevice, then point VMware at that.

This is where a network approach starts to win over “raw physical COM mapping.”

4. When the device is somewhere else or needs sharing

For anything non-trivial, a networked serial solution is cleaner than dragging a COM port into the VM.

If you’ve got a hardware device on another machine, or multiple VMs need to talk to it, look at Serial to Ethernet Connector:

  • Install it on the machine that has the real serial device
  • It exposes that port over TCP/IP as a virtual COM/TTY
  • On your VMware host or inside the guest, create a virtual serial port that talks to that TCP endpoint

From the VM’s perspective, it’s “just a local serial port,” but all traffic runs over the network. That avoids the host/guest contention mess and cable spaghetti.

You can grab it from here:
get powerful serial over IP tools

That combo (VMware serial port + Serial to Ethernet Connector) is especially nice if:

  • The device is in a remote rack
  • You want the same device accessible from more than one VM (with proper discipline, obviously)
  • You might later migrate the VM to another host without replugging anything

5. Practical “what should I pick?” matrix

  • You just want boot logs / kernel panics

    • Quick & dirty: VMware “Output to file”
    • Better: named pipe + socat → real log file with timestamps & rotation

  • You want a real serial console to type into from anywhere

    • VMware named pipe
    • Host tool (socat/ser2net) → TCP port
    • Connect using telnet/ssh tunnel/whatever from your workstation

  • You need to speak to a physical device (PLC, router console, lab gear)

    • If device is local and simple: “Use physical serial port,” but lock it down on the host
    • If device is remote or shared: Serial to Ethernet Connector exposing that port over IP, then point the VM’s virtual serial port to the provided virtual COM/TTY

If you say a bit more about your exact use (OS in guest, OS on host, and whether the device is local or remote), it’s possible to shave even more yak hair off this setup.

4

Skip the virtual serial port. Use normal network tools inside the guest.

Send logs to a seperate syslog server:

. @@192.168.1.20:514

Add this line to /etc/rsyslog.d/remote.conf, then restart rsyslog. Use TCP for fewer dropped messages.

For remote console access, enable SSH and connect with:

ssh admin@vm-address

This setup is simpler to test, secure with SSH keys, and easier to maintain. Your log server will recieve searchable logs without VMware pipe settings or physical port conflicts.

5

If the guest ever loses its network, everything @0xhacker8 suggested falls apart at the exact moment you care about it. SSH and remote syslog are great for a healthy running system, but a serial console exists for the times when the network stack isn’t up yet, the kernel is panicking, or the box is stuck in the bootloader. That’s the whole reason people reach for serial in the first place. So I wouldn’t frame it as ‘skip serial, use SSH.’ They solve different problems. Keep SSH for day to day, keep serial for the disasters.

Small thing that trips people up and nobody mentioned: the serial device usually won’t show up until you power the VM fully off and add it, and you still have to tell the guest kernel to actually use it. On Linux that means a console=ttyS0,115200 on the kernel line, otherwise you get a live VMware pipe that emits nothing and you spend an hour blaming socat. On Windows it’s the bcdedit dance. The VMware side being configured correctly is only half the job.

I mostly agree with @codecrafter on avoiding VMware’s built in file logging. It buffers in ways that will bite you during a crash, which is the one scenario where you want every last byte flushed. Named pipe into socat with append is more work but you actually trust the output. The ser2net over TCP idea is solid too, just don’t leave that port wide open on anything but a trusted segment. Raw telnet to a console is a gift to anyone sniffing the LAN.

On the physical port and Serial to Ethernet Connector angle: it earns its place when the hardware lives somewhere else or two VMs genuinely need the same device, and the contention warnings above are real. But if the device is sitting on the same host as the VM, adding a network hop and a service in the middle is effort you don’t need. Map the physical port directly and lock the host off it. Reach for the networked tool when the cable literally cannot reach, not by default.

If I had to give one rule: pick based on failure mode, not convenience. Console you’ll only ever miss when things are already broken, so set it up to survive a dead network and a hard crash, then layer SSH and remote syslog on top for the normal days.