-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Henrik Nordstrom schrieb: > On Sun, 10 Jul 2005, Oliver Gerlich wrote: > >> what is the best solution to connect the vde "switch" to my real LAN so >> that Qemu guests get IPs from my LAN-wide DHCP server? > > > bridgeing of your ethernet interface and the TAP interface connecting to > vde is undoubtly the best if you want to provide full access to the LAN. > >> So far I've experimented with bridging tap0 and eth0 so that the Qemu >> guests are transparently on my LAN and get IPs from the LAN-wide DHCP >> server. But this has the drawback that my host network interface is now >> br0 instead of eth0 (that causes confusion at least for samba). > > > Fix the Samba problem? > > Why does this cause problems for Samba? I run my qemu stations like this > all the time, but not using Samba..
The "problem" is that I start vde_switch and the bridging not at boot, but when I want to run Qemu. So then I have to restart Samba to bind to to br0 instead of eth0. Not so much of a problem though... Only I don't know what other services already rely on eth0 as my network interface :) Could you explain how you integrated vde_switch and bridging with your current system? Do you start everything at boot and accept that this changes the system-wide network configuration, or do you use some bridging trick to avoid this? > >> Also I tried to set up IP forwarding between tap0 and eth0, but then the >> Qemu guests aren't transparently on my LAN (and don't get the correct >> config from the DHCP server). > > > Correct. > > DHCP is Ethernet broadcast based, not IP. > > You could in theory run a DHCP proxy agent on your tap0 interface, and > have the DHCP server configured with a suitable scope. But this does not > give you addresses from your LAN. > > You could also run a local DHCP server on tap0, configured with the > address scope you have set up proxy-arp for. But these addresses better > be statically assigned to you, never handed out by the LAN DHCP server > to anyone else in the LAN. But this doesn't provide true LAN access, > only routed acces to the LAN (no broadcasts). So it looks indeed that vde and bridging is the way to go. Thanks for your explanations :) > > Regards > Henrik > > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > > Greetings, Oliver -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC0V+KTFOM6DcNJ6cRAtA2AKC7yADYol1HiZ8yGUlg7H1qZSOpqwCgtR4l G/5XEwjQH6Ov1bXfkgkHPs4= =V9ii -----END PGP SIGNATURE----- _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
