QEMU doesn't do a great job of supporting multiple user-net interfaces
right now. I was testing this the other day and getting some rather odd
behavior (unexpected segfaults, etc.) I didn't debug deep enough to
figure out the specifics, but having a global state (like slirp is
today) for multiple network providers is probably not a good idea. I am
contemplating writing a patch that will change the global state in slirp
to an actual "opaque" state, even letting various slirp instances be
configured to serve different subnets, etc. This would be useful if for
example you wanted to have 1 slirp interface access only "special"
services, like smb, etc., and another act as a NAT to the internet. In
that case, in theory, stuff like VPN software in the guest OS should
work without disrupting access to "special" services. But for something
like this to truly work, you need to have the ability to configure the
subnet that slirp sets up _per NIC_, and that would of course mean
removing the global state as the most obvious (and correct IMHO) solution.
Others will probably argue that you can use a combination of a single
slirp NIC and a NAT tun/tap set up to accomplish the same basic thing
today, without any modifications. Still, the "zero" host configuration
of slirp makes it very attractive on its own, so I still think the patch
I'm referring to would be valuable. I'd also implement an option to
make slirp return the DNS/gateway in the DHCP packet for only 1
interface, since guest OS's would probably not like having multiple
default gateways. This patch would be useful in a slightly different
way even if you were trying to combine slirp with tun/tap, and having
the guest OS configured for DHCP on all interfaces. For example, you
may want the guest OS to use the tun/tap interface as the default route,
so telling the slirp interface to not return a gateway/DNS would
probably still be a good idea even if you were only using 1 -net user.
That patch by itself would be trivial versus the global->local state
patch I mentioned above, so I can see posting that one much sooner, if
it even works as I'm expecting it to ;)
Regards,
Leo Reiter
Ed Swierk wrote:
I agree, since the hostname is relevant only for user-net interfaces.
An updated patch is attached.
The only issue is that there's just a single, global hostname, not a
hostname per user-net interface. On the other hand, I'm not sure if
qemu supports multiple user-net interfaces in the first place. Does
the following configuration make sense?
-net nic,vlan=0 -net user,vlan=0 -net nic,vlan=1 -net user,vlan=1
--Ed
--
Leonardo E. Reiter
Vice President of Product Development, CTO
Win4Lin, Inc.
Virtual Computing from Desktop to Data Center
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
