Rob Landley <r...@landley.net> writes: > On 05/13/2011 07:19 AM, Markus Armbruster wrote: >> Rob Landley <r...@landley.net> writes: >> >>> On 05/13/2011 01:54 AM, Markus Armbruster wrote: >>>> Rob Landley <r...@landley.net> writes: >>>> >>>>> On 05/12/2011 09:10 AM, Markus Armbruster wrote: >>>>>> Rob Landley <r...@landley.net> writes: >>>>>> >>>>>>> In 1.14.0, if I did this: >>>>>>> >>>>>>> qemu -net nic,blah -net user -net nic,blah -net tun,blah >>>>>>> >>>>>>> Then the first nic would be -net user, and the second nic would be -net >>>>>>> tun. In current -git, -net user attaches to the second interface and >>>>>>> -net tun attaches to the first, I.E. the order is reversed. >>>>>>> >>>>>>> Either way the first -nic becomes eth0 in Linux and the second becomes >>>>>>> eth1 (I can manually assign mac addresses in order to confirm which is >>>>>>> which), but eth0 used to be the -net user interface and now eth1 is the >>>>>>> -net user interface. >>>>>>> >>>>>>> I bisected this to commit 60c07d933c66c4b30a83b but I don't know why it >>>>>>> changed the behavior, and I can't find _documentation_ on having >>>>>>> multiple interfaces transports hooked up to the same qemu instance >>>>>>> anyway. (It used to work, but possibly that was an accident?) >>>>>>> >>>>>>> Any ideas? >>>>>> >>>>>> Does it happen with -device and -netdev as well? >>>>>> >>>>>> See docs/qdev-device-use.txt for how to go from -net to -device. >>>>> >>>>> Read read read... >>>>> >>>>> That seems to be micromanaging PCI bus slot assignment, which isn't >>>>> changed by this patch. The cards don't move around, nor does the >>>>> association between cards and Linux eth0/eth1. What changes is which >>>>> virtual LAN each virtual ethernet card is plugged into. (The virtual >>>>> cat5 cable coming out of the card moves to a different switch.) >>>> >>>> I didn't mean to tell you "try using -device to juggle PCI addresses". >>>> I meant to steer you away from QEMU VLANs, to find out whether they're a >>>> factor in your problem. Possible, because non-VLAN uses a few different >>>> code paths in QEMU. Sorry if I was too terse. >>>> >>>> In general, my advice is stay away from QEMU VLANs. >>> >>> Ok, now I'm confused. >> >> Sorry :) >> >>> Before this, I wasn't using them. Now I am. What's the reason for >>> avoiding them? (Also, I didn't see a way in -device to specify a >>> network transport, just cards and their properties. Quite possibly I >>> missed it...) >> >> A virtual network device has a host and a guest part. >> >> The modern way to configure host and guest part is -netdev for host and >> -device for guest part. Example: >> >> -netdev user,id=net0 -device e1000,netdev=net0 >> >> (qemu) info network >> Devices not on any VLAN: >> net0: net=10.0.2.0, restricted=n peer=e1000.0 >> e1000.0: model=e1000,macaddr=52:54:00:12:34:56 peer=net0 >> >> One guest part connected to one host part. > > Well, not calling it a "VLAN" which already has at least two other > meanings is less confusing, so I'll give it a shot. (I'm trying to > update my container documentation at http://landley.net/lxc so I don't > just want to get this to work but I want to be able to EXPLAIN it.) > > The name "netdev" is not self-explanatory. FYI. Let's see...
I guess it was chosen for similarity to -chardev. Both create a device host part. > Doesn't like "macaddr". It got gratuitously renamed to "mac=". Eh, > remove that and try again. Documented in docs/qdev-device-use.txt. > qemu-system-x86_64: -netdev id=lan0,user,hostfwd=tcp:127.0.0.1:9876-:22: > Parameter 'type' is missing > > Um, no it isn't? Ok, that argument magically has to be first... "user" is shorthand for "type=user". The short form is only accepted when it comes first. Many option arguments of the form NAME=VALUE... work that way, including -net. > So my third wild guess at redoing my command line worked: > > qemu-system-x86_64 -m 512 -kernel ~/linux/linux/arch/x86/boot/bzImage > -no-reboot -hda squeeze.ext3 -append "root=/dev/hda rw" -netdev > user,id=lan0,hostfwd=tcp:127.0.0.1:9876-:22 -device e1000,netdev=lan0 > -netdev tap,id=lan1,ifname=kvm0,script=no,downscript=no -device > e1000,netdev=lan1 > Warning: more nics requested than this machine supports; some have been > ignored > > I have no idea where that warning came from, but I got both my > interfaces so it's at least working. Relatively recent regression, suspecting commit f68b9d67. Ignore the warning for now. >> For backward compatibility, the older way still works: >> >> -netdev user,id=net0 -net nic,model=rtl8139,netdev=net0 >> >> There's also a completely different kind of host part, called VLAN (not >> related to 802.1q VLANs). Example: >> >> -net user,vlan=0 -device rtl8139,vlan=0 >> >> (qemu) info network >> VLAN 0 devices: >> user.0: net=10.0.2.0, restricted=n >> rtl8139.0: model=rtl8139,macaddr=52:54:00:12:34:56 >> >> You can connect multiple guest parts to it. This is rarely needed, and >> when you need it, you're often better off with a real ethernet bridge, >> see brctl(8). Best stick to -netdev. > > Um, are you saying I CAN'T connect multiple guest parts to -netdev user? Yes. If you want multiple guest NICs on the same ethernet, use a bridge. >> For backward compatibility, the older way still works: >> >> -net user,vlan=0 -net nic,model=rtl8139,vlan=0 >> >> You can omit vlan=0, because it's the default. > > Is the old mechanism ever going to get removed? Does the new one > actually do anything the old one couldn't? Why are there two redundant > mechanisms here anyway? Important optimizations like GSO or vhost-net aren't feasible with -net's VLANs. That's why -netdev got added[*]. VLANs are still around for backward compatibility. I hope we can get of them eventually. >>>>> (The fix was to tag everything with vlan arguments and manually manage >>>>> the association.) >>>> >>>> Glad you got your problem solved. >>> >>> Solved, yes. Understood... less so than I thought, apparently? >> >> Hope the above helps a bit. > > I'm now confused about different things, which is progress. (Possibly > lateral progress, but eh, still new territory.) Let me know whether I've found more ways to confuse you. [*] http://lists.gnu.org/archive/html/qemu-devel/2009-10/msg00858.html
