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

[Anthony Liguori <aliguori@us.ibm.com>]

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.

A policy decides how group a bunch of mechanisms together into a higher 
level thing that's hopefully easier to understand/manage.

> Of course, -net bridge doesn't prevent the management stack from doing 
> management itself (and using -net tap,fd=), but as can be seen from 
> Dan Berrange's response, -net bridge might encourage them into 
> laziness; then we're on the slippery slope of adding more features to 
> -net bridge because libvirt depends on it.  Do you really want to add 
> selinux labelling (whatever that is) to qemu?

If you're real concern is that we're implementing a policy of 'ifconfig 
$tap 0.0.0.0 up && brctl addif $bridge $tap', then I certainly can 
understand where you're coming from.

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.

The only other configuration I've seen with a tap device is to directly 
configure an ip address with it and not use a bridge at all.  That's 
covered by -net tap though and really is not all that useful except for 
benchmarking.

>> 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.

>> 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.

>
> 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?

-- 
Regards,

Anthony Liguori