Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu

[Avi Kivity]

On 11/05/2009 06:19 PM, Anthony Liguori wrote:
> Avi Kivity wrote:
> > No, of course not, I use qemu from the command line and would benefit 
> > from -net bridge.  My badly-conveyed objection is that qemu should 
> > not take a system management role (and enforce system-wide policies) 
> > but leave that to system management tools.
>
> I do not consider this system management functional no more than I see 
> providing a global configuration file as system management 
> functional.  They are both mechanisms.  The ACL file is a mechanism 
> just like VNC sasl ACLs are a mechanism.

I meant system as in outside the scope of a single VM.  VNC 
authentication is for a single VM.  Determining who is allowed to bridge 
where is system-wide functionality.

> However, I think you're wrong to think of that as a policy.  I've seen 
> many exotic network configurations over the years and I've never seen 
> anyone do anything other than that with a tap device.  It really 
> doesn't make sense to do anything more than that.

guest-specific ebtables rules
traffic control / QoS
statistics on the tap interface
vlan encapsulation
selinux labelling (if that makes sense)

> > > I strongly disagree with the way you separate users who use 
> > > management software from people who invoke qemu directly.  libvirt 
> > > and virt-manager are existence proofs that management software 
> > > heavily relies on the defaults and mechanisms we establish within qemu. 
> >
> > So you say, if someone makes a wrong decision, we should fix it by 
> > making the decision ourselves?
> >
> > -net bridge will only dig them deeper into qemu defaults.
>
> I'm suggesting we should get off our ivory tower claiming that 
> management tools should do a better job than they are today and 
> proactively make it easier for them to do the right thing.  We've 
> always touted the improvement of security that qemu/kvm bridges 
> because it allows a guest to run as an unprivileged user.  But this is 
> chart-ware because it's simply not the case today.

Fine, but fix it where it's broken, not in qemu.  Configuring a tap is 
not rocket science, it's just 200 lines.

> > > We can say all we want about how management software should do 
> > > things but the best way is to make it easy for them to do the right 
> > > thing.
> >
> > Except it's not the right thing, at least not completely.  Creating 
> > the tap and attaching it to a bridge is just a part of configuring 
> > networking.  You're making it easy to do that part and impossible to 
> > do the rest.
>
> What is impossible to do with -net bridge?  Certainly, you can still 
> capture the network interface very easily.  You can also still program 
> ebtables rules as it's trivial to discover the name of the network 
> device.

How, through the qemu monitor?

> > Perhaps the same patchset, but to libvirt-devel, would be more useful 
> > since they can then add any extra features without burdening qemu.
>
> Except why limit this functionality to libvirt when it's useful to all 
> management tools?

Because each will need to do something slightly different.

--
error compiling committee.c: too many arguments to function