systemd: Tagging /dev/virtio-ports/* for systemd

Daniel P. Berrange berrange at redhat.com
Wed Jul 6 12:49:03 UTC 2011


On Wed, Jul 06, 2011 at 02:27:58PM +0200, Lennart Poettering wrote:
> On Wed, 06.07.11 10:22, Daniel P. Berrange (berrange at redhat.com) wrote:
> 
> > > So, I am a bit confused now after reading this:
> > > 
> > > http://fedoraproject.org/wiki/Features/VirtioSerial
> > > 
> > > How does /dev/hvcxxx relate to these virtio ports?
> > > 
> > > hvc ports are tagged "systemd" anyway in udev, so if this is the same
> > > thing, why do we have to tag the virtio ports too?
> > > 
> > > Can you explain how hvc and virtio relate to each other and under which
> > > kernel device names they show up in udev and how they correspond?
> > 
> > In QEMU, there is one PCI device "virtio-serial-pci". In QEMU's view this
> > device is a bus to which we then attach zero or more 'virtconsole' or
> > 'virtserialport' devices.
> > 
> > The 'virtconsole' device is a paravirt text console, which appears as
> > /dev/hvcNNN in the guest. These are intended for interactive login and
> > would be expected to run a mingetty/agetty process.
> 
> Hmm, but Unix does not really distuingish between serial ports and
> ttys. So what precisely is the difference in behaviour when I have
> opened a /dev/hvcXX and a /dev/vportXXX? What happens if start a getty
> on /dev/vportXXX? And why couldn't I use /dev/hvcXXX for fast data
> transfer, too?

There's not really any functional difference between them once open.
The difference is is really about providing hints to the guest OS as
to how to configure the devices "out of the box"

The goal for the virtconsole devices was that a guest OS can just
automatically start a getty on every /dev/hvcXXX device it finds.
So a host admin can just add console devices to a guest config and
get a login without any extra guest OS configuration work.

The virtserial devices meanwhile have a admin defined name associated
with them to (in my example 'org.libguestfs.channel.0') so guest OS
agents can have a predictable way to identify which ports have been
exposed from the host for their use.

eg, consider if two guest agents 'guestfsd' and 'matahari' both wanted
to run in a guest and we were using just /dev/hvcXXX devices. There'd
be no way for them to decide which of /dev/hvc0, /dev/hvc1 applied
was theirs. With virtserial devices having a stable name, they can see
which is which device immediately.

> Or is the only difference on the host side? i.e. the destinction between
> access via pty and access via sockets?

No, that was just two example configs - the range of host side config
options is the same for both, with exception that virtserial devices
have an additional 'name' associated with them which maps to the device
/dev/virtio-ports/$NAME in Linux guests.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|


More information about the devel mailing list