xen kernel with dom0 in Fedora 10?

[Daniel P. Berrange]

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 at redhat.com> 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 :|