Anthony Liguori wrote: > Alexander Graf wrote: >> Yeah. Worse than the "run as root" part is the "it's hard" part >> though. I hate how I feel when I try to explain someone how to use >> non-slirp networking :-(. >> >> The response to that is then usually "oh whatever, it's too >> complicated anyways". > > I agree and it's a problem I would like to solve too. > >>> And assuming a bridge is defined named qemubr0 and the administrator >>> has setup >>> permissions accordingly, it will Just Work. My hope is that >>> distributions will >>> do this work as part of the qemu packaging process such that for >>> most users, >>> the out-of-the-box experience will also Just Work. >> >> Yeah, that won't work as easily. >> >> When your customer has 2 NICs this will already break. But let's >> imagine we only have a single NIC. >> >> So that NIC is a wifi card. When I set up the qemubr0 bridge for that >> one now, how does network manager configure my wifi access? It can't >> use the bridge device, as that doesn't have wifi extensions. It also >> can't use the wifi device, because setting up networking on that will >> break. >> >> IMHO the only customer friendly choice I see is the ugly way. The way >> VMware and Vbox do it. >> To make it a bit less ugly, maybe we could create some way to "glue" >> a tap device and an eth together, the same way the bridge code does, >> just without the extra device. > > I don't think that helps either. At the end of the day, this is > really a policy decision. You want to expose the subset of > functionality that the majority of your users require. Inevitably, > you'll leave some users who need more complex setups on their own. > > For instance, users with one NIC are certainly common. Two or more > NICs are also pretty common. But what about people that require > guests to be on separate VLANs? > > This is where management tools come in. When running qemu by hand, > the management tool is the distro more or less as they will be > choosing the default policies. What we need to think about is how to > make sure we can seamlessly integrate with whatever policies they want > to implement. > > I think the one thing we could add is a configurable message to print > when a user tries to use a bridge that isn't configured yet. For > instance, if a user runs qemu without a bridge setup, what would be > nice is the following: > > $ qemu -net bridge -net nic -hda ~/images/linux.img > qemu: error running bridge helper > > You currently do not have 'qemubr0' configured. To setup qemubr0, run > (as root): > zypper install qemu-network-setup > qemu-network-setup qemubr0 > > $ sudo qemu-network-setup > Which interface do you want to configure [qemubr0]: qemubr0 > Do you want to configure qemubr0 as NAT or Bridge [NAT]: Bridge > Which physical interface do you want to bridge qemubr0 to [eth0]: eth0 > qemubr0 is now configured. > > I expect that this is going to be different for every distro. netcf > my make this easier but for now, I think this is the most realistic > approach.
Well I'm not that familiar with the bridging stuff as I'm rather scared by it myself, but last time I tried if I # brctl addif br0 eth0 # ifconfig br0 up eth0 stopped working, so I had to stop network manager, assign an IP to br0 manually and hope network manager doesn't kick in again. I don't see how we can solve that easily, as most people will want to use NM. Alex
