qemu-devel
[Top][All Lists]
Advanced

[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:25:44 -0600
User-agent: Thunderbird 2.0.0.23 (X11/20090825)

Avi Kivity wrote:
That's short sighted. If we just focus on "making a guest work" we'll end up with crappy interfaces that cripple management tools.

Only with management tools that cripple themselves. It's pretty easy to get unprivileged bridging with -net tap; it's just that libvirt hadn't gotten around to it yet -- see Dan's comment. Are you going to take on every libvirt deficiency and push it into qemu?

No, but I'd like avoid forcing management tools to introduce these deficiencies in the first place.

If users are constantly struggling to do even the simplest things with qemu, then it doesn't matter how well our "guest works". No one will use it.

That's not the case today, even with virt-manager.

I'm not going to pick on any particular tool, but kvm absolutely has a reputation of being difficult to use compared to other virtualization software out there. Nothing else requires modifying configuration files just to get a guest with bridged networking.

I think we absolutely have to think about the full stack and how all the pieces interact. There are definitely problems in the stack right now. Security is the one I'm trying to address in this series. If you cannot launch a reasonable configured qemu from the command line as an unprivileged user, there's really no hope that we can expect a management tool to do that.

I'm almost offended on Dan's behalf.

We'll I guess it's about perspectives then. I don't see the fact that libvirt runs qemu as root as a libvirt deficiency. I see it as a qemu deficiency.

Again, there are no shortage of existence proofs of this (beyond libvirt). I suspect there isn't a management tool out there that does the right thing today.

RHEV-H launches guests as unprivileged users; the management daemon is also unprivileged.

I suspected as much based on how strongly you were advocating this. I think my point still stands though, there's an awful lot of management software out there that gets it wrong. It's great that you guys got it right but so far, the majority of users are not using qemu through RHEV-M so I still think we have a problem.

Regards,

Anthony Liguori

--
Regards,

Anthony Liguori





reply via email to

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