RFC: Who wants/cares about SLiRP networking for QEMU?

RFC: Who wants/cares about SLiRP networking for QEMU?

[Scott Garman]

This is an inquiry to see if there's much interest in adding an 
alternate networking capability for our QEMU setups. Currently, we use 
tun/tap devices, which need root privileges to be created. Hence, our 
runqemu script requires sudo access.

I'm curious to know who would like to see us use an alternate mechanism 
(most likely SLiRP) to get around the need for sudo access. Is this much 
of a problem for anyone, or would the team's resources be better spent 
on other bugfixes?

Secondly, does anyone have any war stories about using SLiRP for this 
purpose? Is there a better way we should consider doing this?

Thanks,

Scott

-- 
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center

Re: RFC: Who wants/cares about SLiRP networking for QEMU?

[Jason Wessel]

On 05/08/2012 08:19 PM, Scott Garman wrote:
> This is an inquiry to see if there's much interest in adding an 
> alternate networking capability for our QEMU setups. Currently, we use 
> tun/tap devices, which need root privileges to be created. Hence, our 
> runqemu script requires sudo access.
>
> I'm curious to know who would like to see us use an alternate mechanism 
> (most likely SLiRP) to get around the need for sudo access. Is this much 
> of a problem for anyone, or would the team's resources be better spent 
> on other bugfixes?
>
> Secondly, does anyone have any war stories about using SLiRP for this 
> purpose? Is there a better way we should consider doing this?

We have QEMU + UserMode NFS + SLiRP for years in Wind River Linux products.   In that period I have sent upstream most of the patches dealing with problems.  There remain a few patches to the User Mode NFS service which are not currently in the Yocto project.  I also have a patch that is not in the QEMU mainline that deals with syn packets where QEMU violates the RFC that was never merged upstream for some reason.  I imagine that you will probably want all those patches if that is going to be your mode of operation.

You will also want to create a mechanism to easily add port redirections.  Typically we have always used what we call an simulator "instance" number so we know the ports are at generally fixed locations and for each instance number all the port redirections are incremented by 100.

Cheers,
Jason.

Re: RFC: Who wants/cares about SLiRP networking for QEMU?

[Scott Garman]

On 05/08/2012 06:28 PM, Jason Wessel wrote:
> On 05/08/2012 08:19 PM, Scott Garman wrote:
>> This is an inquiry to see if there's much interest in adding an
>> alternate networking capability for our QEMU setups. Currently, we
>> use tun/tap devices, which need root privileges to be created.
>> Hence, our runqemu script requires sudo access.
>>
>> I'm curious to know who would like to see us use an alternate
>> mechanism (most likely SLiRP) to get around the need for sudo
>> access. Is this much of a problem for anyone, or would the team's
>> resources be better spent on other bugfixes?
>>
>> Secondly, does anyone have any war stories about using SLiRP for
>> this purpose? Is there a better way we should consider doing this?
>
> We have QEMU + UserMode NFS + SLiRP for years in Wind River Linux
> products.   In that period I have sent upstream most of the patches
> dealing with problems.  There remain a few patches to the User Mode
> NFS service which are not currently in the Yocto project.  I also
> have a patch that is not in the QEMU mainline that deals with syn
> packets where QEMU violates the RFC that was never merged upstream
> for some reason.  I imagine that you will probably want all those
> patches if that is going to be your mode of operation.
>
> You will also want to create a mechanism to easily add port
> redirections.  Typically we have always used what we call an
> simulator "instance" number so we know the ports are at generally
> fixed locations and for each instance number all the port
> redirections are incremented by 100.

Thanks Jason, this is exactly the kind of info I was hoping to learn 
about. It's possible/likely that I may not end up implementing this 
myself, but if the feature gets reassigned, I will make sure the 
implementor gets connected to you for those patches.

Thanks,

Scott

-- 
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center