Hello,
VirtualBox when run as a userspace tool would not require root password, not chown ISOs and VMs are created with regular user privileges. Virt-Manager on the other hand requires root password, changes ISO's owner to either qemu or root and VMs also created under root user. Personally using root for such a trivial task is not prefered. I can start Virt-Manager without root password using this guide [1] but other two doesn't seem to be possible. Anyone know anything about the issues I am facing.
[1] https://ask.fedoraproject.org/en/question/49928/install-fedora-vm-with-updat...
Greetings,
----- Original Message from Sudhir Khanger -----
VirtualBox when run as a userspace tool would not require root password, not chown ISOs and VMs are created with regular user privileges. Virt-Manager on the other hand requires root password, changes ISO's owner to either qemu or root and VMs also created under root user. Personally using root for such a trivial task is not prefered. I can start Virt-Manager without root password using this guide [1] but other two doesn't seem to be possible. Anyone know anything about the issues I am facing.
[1] https://ask.fedoraproject.org/en/question/49928/install-fedora-vm-with-updat...
I didn't see anything at that URL that about how to start Virt-Manager without the root password.
Oddly, I don't need the root password to start virt-manager. My user was setup as an "Adminstrator" (aka, the account has sudo access) so I only need to type in my user password. That's how most people do it.
TYL,
On 07/12/2014 11:20 PM, Sudhir Khanger wrote:
Hello,
VirtualBox when run as a userspace tool would not require root password, not chown ISOs and VMs are created with regular user privileges. Virt-Manager on the other hand requires root password, changes ISO's owner to either qemu or root and VMs also created under root user. Personally using root for such a trivial task is not prefered. I can start Virt-Manager without root password using this guide [1] but other two doesn't seem to be possible. Anyone know anything about the issues I am facing.
I wouldn't exactly describe virtualization management as a trivial task :)
virt-manager defaults to using the libvirt URI qemu:///system, which connects to the system libvirtd instance, which runs as root. What you're requesting is basically the qemu:///session URI, which auto-launches a libvirtd instance running as your regular user, runs VMs as your user, and defaults to storing images in $HOME/VirtualMachines. You can use that like 'virt-manager --connect qemu:///session' or File->Add Connection->QEMU/KVM user session in new enough virt-manager.
There's a lot of reasons why virt-manager doesn't default to qemu:///session, here's the two big ones:
- Networking: historically the only real networking mode available with qemu:///session is usermode networking, which has limited functionality compared to what some users will expect by default. See http://wiki.qemu.org/Documentation/Networking#User_Networking_.28SLIRP.29
- Historical reasons: when virt-manager first grew qemu/kvm support, qemu:///session couldn't even be used for actual KVM acceleration, which would have made it a poor default. Nowadays that is no longer true, but to change the default would require serious work: either lots of documentation and warnings to explain to users the subtle differences between qemu:///system and qemu:///session and importing of pre-existing VMs, or lots of work to try and narrow the functionality gap between the two methods.
The chown'ing and selinux labeling of any storage attached to a VM is a libvirt security feature that's not virt-manager's explicit doing. It has historically been quite a pain WRT install media as you've likely discovered. I've had a long standing todo item to fully investigate the issues that people hit and try and come up with a solution, whether it's libvirt fixes, virt-manager fixes, or just better error messages. But I haven't gotten around to it yet.
- Cole
On Sunday, July 27, 2014 03:56:12 PM Cole Robinson wrote:
virt-manager --connect qemu:///session
Thanks Cole for the explanation. User session is what I wanted. I will go ahead and read more about it.
On Sun, Jul 27, 2014 at 03:56:12PM -0400, Cole Robinson wrote:
- Networking: historically the only real networking mode available with
qemu:///session is usermode networking, which has limited functionality compared to what some users will expect by default. See http://wiki.qemu.org/Documentation/Networking#User_Networking_.28SLIRP.29
Sorry, just catching up on this list.
"historically" .. meaning there is something better than SLIRP available for non-root users now?
The chown'ing and selinux labeling of any storage attached to a VM is a libvirt security feature that's not virt-manager's explicit doing. It has historically been quite a pain WRT install media as you've likely discovered. I've had a long standing todo item to fully investigate the issues that people hit and try and come up with a solution, whether it's libvirt fixes, virt-manager fixes, or just better error messages. But I haven't gotten around to it yet.
The central pain point for me is around NFS. Put a disk image on NFS, and libguestfs breaks (because of labelling). You have to use 'export LIBGUESTFS_BACKEND=direct' to work around it.
Rich.
On 09/30/2014 09:38 AM, Richard W.M. Jones wrote:
On Sun, Jul 27, 2014 at 03:56:12PM -0400, Cole Robinson wrote:
- Networking: historically the only real networking mode available with
qemu:///session is usermode networking, which has limited functionality compared to what some users will expect by default. See http://wiki.qemu.org/Documentation/Networking#User_Networking_.28SLIRP.29
Sorry, just catching up on this list.
"historically" .. meaning there is something better than SLIRP available for non-root users now?
You can use the setuid qemu-bridge-helper to let a non-root qemu use virbr0 provided by the default network. That's what boxes does now. But you have to hope that virbr0 is set up correctly, since non-root libvirtd can't manage it.
- Cole
On Tue, Sep 30, 2014 at 09:42:44AM -0400, Cole Robinson wrote:
On 09/30/2014 09:38 AM, Richard W.M. Jones wrote:
On Sun, Jul 27, 2014 at 03:56:12PM -0400, Cole Robinson wrote:
- Networking: historically the only real networking mode available with
qemu:///session is usermode networking, which has limited functionality compared to what some users will expect by default. See http://wiki.qemu.org/Documentation/Networking#User_Networking_.28SLIRP.29
Sorry, just catching up on this list.
"historically" .. meaning there is something better than SLIRP available for non-root users now?
You can use the setuid qemu-bridge-helper to let a non-root qemu use virbr0 provided by the default network. That's what boxes does now. But you have to hope that virbr0 is set up correctly, since non-root libvirtd can't manage it.
OK .. be nice to get this working some time with libguestfs, for those libguestfs applications that use the (not-enabled-by-default) network support. eg. virt-builder, virt-customize, virt-rescue --network.
Especially having 'ping' work would be a major breakthrough :-)
When you say "virbr0 is set up correctly" does that mean virbr0 is set up using the 192.168.122 network, or just that virbr0 exists and is working in some respect? Most of my machines have virbr0 bridged to the physical ethernet device.
Rich.
On 09/30/2014 09:50 AM, Richard W.M. Jones wrote:
On Tue, Sep 30, 2014 at 09:42:44AM -0400, Cole Robinson wrote:
On 09/30/2014 09:38 AM, Richard W.M. Jones wrote:
On Sun, Jul 27, 2014 at 03:56:12PM -0400, Cole Robinson wrote:
- Networking: historically the only real networking mode available with
qemu:///session is usermode networking, which has limited functionality compared to what some users will expect by default. See http://wiki.qemu.org/Documentation/Networking#User_Networking_.28SLIRP.29
Sorry, just catching up on this list.
"historically" .. meaning there is something better than SLIRP available for non-root users now?
You can use the setuid qemu-bridge-helper to let a non-root qemu use virbr0 provided by the default network. That's what boxes does now. But you have to hope that virbr0 is set up correctly, since non-root libvirtd can't manage it.
OK .. be nice to get this working some time with libguestfs, for those libguestfs applications that use the (not-enabled-by-default) network support. eg. virt-builder, virt-customize, virt-rescue --network.
Especially having 'ping' work would be a major breakthrough :-)
When you say "virbr0 is set up correctly" does that mean virbr0 is set up using the 192.168.122 network, or just that virbr0 exists and is working in some respect? Most of my machines have virbr0 bridged to the physical ethernet device.
I just meant 'virbr0 exists'. Which requires libvirt-daemon-config-network to be installed, the 'default' network to be running and set to autostart.
- Cole
On Tue, Sep 30, 2014 at 10:04:51AM -0400, Cole Robinson wrote:
I just meant 'virbr0 exists'. Which requires libvirt-daemon-config-network to be installed, the 'default' network to be running and set to autostart.
Thanks - I have filed an RFE bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1148012
Rich.
-
Cole Robinson -
Richard W.M. Jones -
Scott Dowdle -
Sudhir Khanger