On Fri, Oct 03, 2008 at 02:41:05PM -0400, James Ralston wrote: > On 2008-10-03 at 18:17+01 Daniel P Berrange <berrange@xxxxxxxxxx> wrote: > > No, [setting up KBM bridge networking] is utterly trivial > > > > # cd /etc/sysconfig/network-script > > > > # cat > ifcfg-eth0 <<EOF > > DEVICE=eth0 > > HWADDR=00:16:76:D6:C9:45 > > ONBOOT=yes > > BRIDGE=br0 > > EOF > > > > # cat > ifcfg-br0 <<EOF > > DEVICE=br0 > > TYPE=Bridge > > BOOTPROTO=dhcp > > ONBOOT=yes > > EOF > > > > # service network restart > > You have a very strange definition of "utterly trivial", then. :p It is trival from an implementation POV. If you have the skills to configure a regular network interface, it is no harder to do bridging. I accept it is badly documented though, hence why we created that wiki page. > First, you have to *know* that you need to do this. One's first clue > is an empty drop-down box in virt-manager's network configuration > options when you're creating a new guest. After much Googling, if > you're lucky, you'll stumble across the KVM wiki and read the > networking section. Then you have to figure out how much of that is > actually appropriate to Fedora + virt-manager. Then you have to make > the above changes (and possibly reconfigure any iptables rules you had > set up). > > How many end users (or, for that matter, unseasoned system > administrators) do you realistically think are going to make it through > that whole process? There's two different audiences really - people who are serious server administrators used to setting up crazy stuff like bonding, vlans, bridging. This is not hard for them. Then, there is casual deskop user / developer who aren't familiar with more complex networking configs. The long term goal is that network manager should be addressing their needs. We don't want to implement bridging control APIs in libvirt, because that's just a short term hack - when people should really be focused on making NetworkManager better > To claim "out of the box" support for KVM bridge networking, > virt-manager has to be able to do all of this automatically. That > means that either virt-manager itself needs to know how to turn a > physical device into a bridged device, or anaconda needs to do this at > system install time. (E.g., any physical device configured with a > fixed IP address is automatically created as a bridge.) It works out of the box for NAT based networking. That's the only config you can reasonably expect to configure out of the box without any user interaction, because anything else requires an understanding of the deployment environment we simply can't get right. > > Job done, virt-manager will show you that br0 bridge and allow you > > to attach a guest to it > > Actually, that *didn't* work for quite a while (the guest would > launch, but networking was non-functional). However, I just now > re-tested, and you're right; virt-manager will Do The Right Thing (as > long as you've manually configured the bridge, that is). Thta was a bug when DBus became more strict in how it wanted to be called, and virt-manager was accidentally violating its rules. > > or out of the box you can use the 'virbr0' for NAT based > > connectivity that works even with wifi + network manager. > > That's the best solution for mobile devices, for sure, but for > virtualizing a server, bridge networking is the only realistic option. > And right now, user-friendly support for that is sorely lacking. We aim NAT'ing at desktop/laptop users, while briding is for server admins who are usually familiar with configuring network devices from sysconfig scripts Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
