VMware Virtual Serial Ports


Virtual Serial Ports are virtual devices that you can add to a VM. As their name suggests, the VM sees them as serial devices. You can map them to a physical serial port on an ESX host, connect them to a file in a datastore somewhere, or configure them to work over the network. This guide will focus on networked virtual serial ports configured in a server role, which means that the virtual serial port is configured to wait for connections from clients. It is possible to configure virtual serial ports to act as clients, in which case they will initiate a connection to some other machine, but I haven't explored that feature because I don't have a use case for it.

What is a concentrator?

A concentrator is an intermediary between clients who want to access virtual serial ports on VMs and the ESX hosts on which those VMs run. A concentrator relays traffic to VMs on behalf of clients, and relays traffic to clients on behalf of VMs. It is possible to use virtual serial ports without a concentrator, but it is undesirable for a number of reasons (it breaks vMotion, it's inconvenient for clients, etc). As the user-facing front end to a collection of virtual serial ports, concentrators can be used to enforce authentication, impose mutual exclusion, implement logging, and (I imagine) a variety of other useful things.

Use cases for concentrators

The use cases for a virtual serial port concentrator are, I'd imagine, fairly similar to the use cases for a physical serial port concentrator. For us, important use cases included:

Concentrator Software

I'm aware of two programs that implement VMware's concentrator software protocol.

Avocent makes the ACS v6000 appliance if you're willing to pay for a concentrator (or want paid support for one). I've never used the Avocent concentrator, so I can't comment on how good or bad it is; you should read my mention of it as a statement of the fact that it exists, not as an endorsement.

There's also vSPC.py, a FOSS VMware virtual serial port concentrator. There are two variants of vSPC.py. vSPC.py was originally written by Zach Loafman, and made available as a SourceForge project [2]. There's also my fork, which I've made available on github and described on another page [3]. We're planning to use my fork of vSPC.py.


The general process of configuration is fairly simple. First, you need to add a virtual serial port device to your VM. You'll want to configure it as a network serial port, and you'll want to configure it to run as a server. Check the box for a virtual serial port concentrator. In the vSPC box, you'll want to enter a URI of the form protocol://hostname:port, where hostname is the host running the virtual serial port concentrator, and port is the port that the concentrator listens on for connections. Protocol can be telnet or telnets; read the security section for more information on the right choice for your environment. The right value for Port URI depends on your concentrator. If you're using vSPC.py, then enter vSPC.py. Despite the fact that you configured your virtual serial port as a server, it will initiate a connection to the concentrator. This is normal. I think that server is meant to be a conceptual thing instead of a statement of whether a socket will be listening for connections in the literal sense; after it connects to the concentrator, the virtual serial port acts a server, in that clients from the concentrator conceptually initiate connections to it.

You'll also need to allow enough network access for the communications to happen. The concentrator will need to accept connections from ESX hosts to the concentrator, and will need to be able to send data to the ESX hosts. The ESX hosts will need to be able to initiate connections with the concentrator, and to receive data from the concentrator.


By default, networked virtual serial port communication happens in the clear. The specification-like document provided by VMware [1] alludes to secure telnet support. From what I can tell, this means telnet over unauthenticated TLS/SSL. On the vSphere side, you enable this be choosing telnets instead of telnet when specifying the vSPC to connect to. On the concentrator side, listening for an SSL connection (and starting SSL over incoming connections from ESX hosts) seems to do the trick. I've contributed a patch to vSPC.py to add SSL support, which seems to accept secure telnet connections.

The lack of authentication is a bit of a letdown. Essentially, it means that vSphere ignores the certificate presented by the virtual serial port concentrator, and doesn't offer a way to configure the certificate that it presents to the concentrator when connecting. As a result, neither the concentrator nor the ESX hosts can be sure that they are connected to the machine that they think they are. The main practical impact of this is that the concentrator is unable to tell the difference between a legitimate ESX host and an attacker's machine when serving connections. An attacker could connect to the concentrator and impersonate a VM, then trick administrators into entering sensitive information into the console associated with the fake VM. A workaround for this is to restrict incoming connections to the concentrator such that only ESX hosts are allowed to connect. Otherwise, we're worried about an attacker who can manipulate the environment around the endpoints such that packets intended for one destination go somewhere else. Depending on your environment, this may or may not be a major concern. In any case, if you feel compelled to use secure telnet, be sure to consider whether it is still useful to you without authentication.

I've filed a feature request with VMware to add authentication, and will update this guide if and when it is implemented.

Documentation and References