Re: [Qemu-devel] virtio-serial: A guest <-> host interface for simple communication

[Amit Shah <amit.shah@redhat.com>]

On (Wed) Jun 24 2009 [18:50:02], Jamie Lokier wrote:
> Amit Shah wrote:
> > On (Wed) Jun 24 2009 [17:40:49], Jamie Lokier wrote:
> > > Amit Shah wrote:
> > > > A few sample uses for a vmchannel are to share the host and guest
> > > > clipboards (to allow copy/paste between a host and a guest), to
> > > > lock the screen of the guest session when the vnc viewer is closed,
> > > > to find out which applications are installed on a guest OS even when
> > > > the guest is powered down (using virt-inspector) and so on.
> > > 
> > > Those all look like useful features.
> > > 
> > > Can you run an application to provide those features on a guest which
> > > _doesn't_ have a vmchannel/virtio-serial support in the kernel?
> > > 
> > > Or will it be restricted only to guests which have QEMU-specific
> > > support in their kernel?
> > 
> > libguestfs currently uses the -net user based vmchannel interface that
> > exists in current qemu. That doesn't need a kernel that doesn't have
> > support for virtio-serial.
> 
> That's great!
> 
> If that works fine, and guest apps/libraries are using that as a
> fallback anyway, what benefit do they get from switching to
> virtio-serial when they detect that instead, given they still have
> code for the -net method?

Speed is the biggest benefit.

> Is the plan to remove -net user based support from libguestfs?

I don't know what Richard's plan is, but if the kernel that libguestfs
deploys in the appliance gains support for virtio-serial, there's no
reason it shouldn't switch.

> Is virtio-serial significantly simpler to use?

I think the interface from the guest POV stays the same: reads / writes
to char devices. With virtio-serial, though, we can add a few other
interesting things like names to ports, ability to hot-add ports on
demand, request notifications when either end goes down, etc.

		Amit