[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu
Date: Thu, 05 Nov 2009 10:19:08 -0600
User-agent: Thunderbird (X11/20090825)

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


Anthony Liguori

reply via email to

[Prev in Thread] Current Thread [Next in Thread]