[fedora-virt] Prevent virt-manager from chowning ISOs

[Sudhir Khanger]

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-updates/

[Scott Dowdle]

Greetings,

----- Original Message from Sudhir Khanger -----

Post by 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-updates/

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,

[Cole Robinson]

Post by Sudhir Khanger
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

[Sudhir Khanger]

Post by Cole Robinson
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.

[Richard W.M. Jones]

Post by Cole Robinson
- 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?

Post by Cole Robinson
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.

[Cole Robinson]

Post by Richard W.M. Jones

Post by Cole Robinson
- 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

[Richard W.M. Jones]

Post by Cole Robinson

Post by Richard W.M. Jones

Post by Cole Robinson
- 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.

[Cole Robinson]

Post by Richard W.M. Jones

Post by Cole Robinson

Post by Richard W.M. Jones

Post by Cole Robinson
- 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

[Richard W.M. Jones]

Post by Cole Robinson
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.