On Thu, 11 Aug 2005, Jim C. Brown wrote:
Incidently, if you have eth0 and eth1, and both are connected to the same LAN, then it works. Just set up vde_packet/pcacp on eth1, then packed tp the host from the VDE will be sent out over eth1 and recieved back in eth0.
Right. Just don't set an IP on eth1 (only link up, no addressing). Frames sent by the guest to the host will travel eth0 -> switch -> eth1.
This solves the problem quite nicely, and it is probably the simplest to implement, but requires changing the hardware. I'm trying to figure out how to achieve the same effect with eth0 and tap0 (as opposed to eth0 and eth1).
Not easily done as you are then missing the switch component looping the frames back to eth0.
If we had a), then vde_pcap would "just work" - there'd be no need to fiddle with faking things on tap devices or etc.
Not fully. Without having the bridge component in the mix frames sent by the guest to the host is likely to be echoed out on the LAN.
Most of these are my goals as well (except I don't mind having to run a bit of glue in a startup script).
If you are prepared to run a bit of glue in system startup scripts then use bridgeing with a tap device. This provides the absolutely cleanest networking capabilities.
The setup I am running is working very well, with only a very small amount of glue required in the Linux system startup. As already shown in this thread such glue can be minimized to almost no changes on the host.
By using a persistent tap device the whole thing can even be run in such manner that all the userspace components (be this vde, or qemu directly) can run as the user when needed. No root rights required.
Regards Henrik _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
