Libguestfs - May 2011 - supermin appliances and host connectivity

On Tue, May 31, 2011 at 10:28:04PM +0200, Joel Uckelman
wrote:
> What I'm having trouble with, and the reason I'm writing you, is
that
> it's not clear to me how much needs to be added to a supermin
> appliance built following your instructions to either (1) enable
> networking, or (2) create a bidirectional pipe with the host. (Really
> all we need is a pipe, networking is actually overkill.)
> 
> Is this making sense? Is there a straightforward way to do this?
Yes, that's what we do in libguestfs.  In fact both things: we create
a bi-directional pipe, and we optionally enable full IP networking.  I
suggest TBH you just look at the code, as that's simpler than me
explaining it:

http://git.annexia.org/?p=libguestfs.git;a=blob;f=src/launch.c;h=0b15ce98d79fac55032a7e93788f62d0011e8c34;hb=HEAD#l392

The key words are "virtio serial" and "user networking".

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v

On Wed, Jun 1, 2011 at 3:06 PM, Joel Uckelman
<joel at lightboxtechnologies.com> wrote:
> On Tue, May 31, 2011 at 10:39 PM, Richard W.M. Jones <rjones at
redhat.com> wrote:
>> On Tue, May 31, 2011 at 10:28:04PM +0200, Joel Uckelman wrote:
>>> What I'm having trouble with, and the reason I'm writing
you, is that
>>> it's not clear to me how much needs to be added to a supermin
>>> appliance built following your instructions to either (1) enable
>>> networking, or (2) create a bidirectional pipe with the host.
(Really
>>> all we need is a pipe, networking is actually overkill.)
>>>
>>> Is this making sense? Is there a straightforward way to do this?
>>
>> Yes, that's what we do in libguestfs. ?In fact both things: we
create
>> a bi-directional pipe, and we optionally enable full IP networking. ?I
>> suggest TBH you just look at the code, as that's simpler than me
>> explaining it:
>>
>>
http://git.annexia.org/?p=libguestfs.git;a=blob;f=src/launch.c;h=0b15ce98d79fac55032a7e93788f62d0011e8c34;hb=HEAD#l392
>>
>> The key words are "virtio serial" and "user
networking".
>
> I think I've fished out the command-line options you send to qemu-kvm:
>
> qemu-kvm -kernel kernel -initrd initrd -hda root -device virtio-serial
> -serial stdio -chardev
>
socket,path=/home/uckelman/projects/lightbox/supermin/foo,id=channel0,name=org.libguestfs.channel.0
>
> Thanks for that.
>
> I can definitely run my appliance this way if I already have something
> listening on that FIFO before launching qemu. (E.g.: socat
> UNIX-LISTEN:foo STDOUT) The piece of the puzzle I'm still missing is
> how to connect to the socket from the guest side. I was expecting to
> find something in the guest's /dev, but I have the same entries there
> as before.
>
I think I've fished out the command-line options you send to qemu-kvm:

qemu-kvm -kernel kernel -initrd initrd -hda root -device virtio-serial
-serial stdio -chardev
socket,path=/home/uckelman/projects/lightbox/supermin/foo,id=channel0,name=org.libguestfs.channel.0

Thanks for that.

I can definitely run my appliance this way if I already have something
listening on that FIFO before launching qemu. (E.g.: socat
UNIX-LISTEN:foo STDOUT) The piece of the puzzle I'm still missing is
how to connect to the socket from the guest side. I was expecting to
find something in the guest's /dev, but I have the same entries there
as before.