qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: guestfwd option doesn't allow supplementary , server, n


From: Jan Kiszka
Subject: [Qemu-devel] Re: guestfwd option doesn't allow supplementary , server, nowait
Date: Tue, 21 Jul 2009 19:39:39 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

Richard W.M. Jones wrote:
> The option formerly known as -net channel was changed to:
> 
>   -net user,guestfwd=[tcp]:server:port-dev
> 
> which in general would be an improvement.  libguestfs currently uses:
> 
>   -net channel,6666:unix:/some/path,server,nowait
> 
> which works (probably by accident, because the code happens not to use
> get_param_value).

I suspect so...

>  However in the new syntax that would be:
> 
>   -net user,guestfwd=tcp:10.0.2.4:6666-unix:/some/path,server,nowait
> 
> This gives errors like:
> 
>   qemu: invalid parameter 'server,nowait' in 
> 'vlan=0,guestfwd=tcp:10.0.2.4:6666-unix:/tmp/libguestfshRZgxr/sock,server,nowait'

Yep, that case does not fit into the syntax of comma-separated
arguments. We need to find a new syntax within the given constraints.
Need to think about it.

> 
> It seems like the code tries to do the right thing for the hostfwd and
> guestfwd parameters.  There is a while loop which seems to check for
> these parameters explicitly, but it doesn't work -- I'm not sure why.

What is your precise qemu command line? I noticed that omitting "-net
user" while specifying "-net channel" seems to miss instantiating a
default slirp stack. That should be easy to fix, will have a look. If
your problem is a different one, please describe the details.

> 
> libguestfs is continuing to use the old, working -net channel form of
> this parameter, so please don't remove it.

It won't be removed in the foreseeable future for backward
compatibility. But we also need to fix the new format as the old one
does not allow to specify the slirp stack it should be apply to.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux




reply via email to

[Prev in Thread] Current Thread [Next in Thread]