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

[Daniel P. Berrange]

On Tue, Jul 05, 2011 at 08:40:55PM +0200, Lennart Poettering wrote:
> On Tue, 05.07.11 20:36, Lennart Poettering (mzerqung at 0pointer.de) wrote:
> 
> > > > We'd like to request that virtio-serial devices (/dev/virtio-ports/*)
> > > > are tagged so we can use them as systemd devices.  Dan Berrange thinks
> > > > the right incantation is to add:
> > > > 
> > > > SUBSYSTEM=="virtio-ports", TAG+="systemd"
> > > > 
> > > > to /lib/udev/rules.d/99-systemd.rules
> > > 
> > > The goal is that we want to automagically run /usr/sbin/guestfsd
> > > when /dev/virtio-ports/org.libguestfs.channel.0 is present. For
> > > this I believe we need to have a '.device' unit for the virtio-port
> > > device populated from the above udev rule, so we can in turn have a
> > > guestfsd.service unit looking like:
> > 
> > I think adding such a rule to systemd's unit file is not a bad idea, but
> > since the use case here is very specific to your app, another option
> > would be to add an app-specific udev rule for this. (See below)
> 
> Oops, wanted to write "systemd's udev rules file" here, and not
> "systemd's unit file".
> 
> > Either way I have now added to git a patch that marks virtio ports for
> > exposure in systemd, by marking them with "systemd".
> 
> 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.

You can enable this in a libvirt guest by changing the default

    <console type='pty'/>

To

    <console type='pty'>
      <target type='virtio'/>
    </console>

Which should create a /dev/hvc0 in the guest

The 'virtserialport' device is a paravirt serial port (though it has
no baud/parity settings). These are basically reliable, bi-directional
data channels between host & guest. These are intended for running
guest agents which need to communicate with some host service. These
appear as unstable named devices /dev/vportNNNN, and also stable named
symlinks /dev/virt-port/UNIQUE-CHANNEL-NAME

You can enables these in a libvirt guest by adding devices like

    <channel type='unix'>
      <source mode='connect' path='/var/lib/libvirt/myguest-org.myservice'/>
      <target type='virtio' name='org.myservice'/>
    </channel>

This should create a character device /dev/virtio-port/org.myservice in
the guest, which is connected to a UNIX socket '/var/lib/libvirt/myguest-org.myservice'
in the host OS.

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 :|