Ken Moffat wrote:
Running it as a user seems like the correct thing to do. We
already say
| You will need a dedicated group that will contain users (other than
|root) allowed to access the KVM device. Add the group by running the
|following command as the root user:
|
|groupadd -g 61 kvm
Yes, we do that. What do you suggest that we do then? We can change the
group of /usr/bin/qemu* to kvm and set them sgid.
I'm in the kvm group and have no problem using the /usr/bin/qemu-*
binaries (so far I've only used -img and -system-*, is there a
reason why any of the otehrs would casue a problem ?).
The way it is now, when I run qemu as a regular user I get
qemu: -net tap: could not configure /dev/net/tun: Operation not permitted
qemu: -net tap: Device 'tap' could not be initialized
Even though /dev/net/tun has 666 permissions. I'm not sure what is
rejecting the configuration.
We would also need to do
that for /usr/sbin/brctl and /sbin/ip to get networking to work.
Looking at the above, should brctl be moved to /sbin?
For my use case, bridge-utils provide no benefit. I do not agree
with the phrase "One problem with the above networking solution is
that it does not provide the ability to connect with the local
network.", but I am uncertain exactly what problem bridge-utils
solves : does it let you connect to the host ?
Let's say you are on machine A and want to run qemu (virtual system C)
on machine B. If you want to ssh into the qemu system, how do the
network packets get forwarded from A to C? The only way I could see to
do that is via a bridge on B that has both the ip addresses for B and C.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
