[PATCH] launch: show hint to resolve authentication failure from libvirt
Signed-off-by: Olaf Hering <olaf@aepfle.de> --- Switching from attach-method "appliance" to "libvirt" has surprising side effects, so show a hint how to resolve the "authentication failed" error from libvirt. Patch is not compile tested. src/libvirtdomain.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/libvirtdomain.c b/src/libvirtdomain.c index eecea26..110ee86 100644 --- a/src/libvirtdomain.c +++ b/src/libvirtdomain.c @@ -104,6 +104,8 @@ guestfs__add_domain (guestfs_h *g, const char *domain_name, err = virGetLastError (); error (g, _("could not connect to libvirt (code %d, domain %d): %s"), err->code, err->domain, err->message); + if (err->code == VIR_ERR_AUTH_FAILED) + error (g, _("Possible fix: 'polkit-auth --user <username> --grant org.libvirt.unix.manage'")); goto cleanup; } -- 1.7.12.2
On Wed, Oct 10, 2012 at 05:06:37PM +0200, Olaf Hering wrote:
Signed-off-by: Olaf Hering <olaf@aepfle.de> ---
Switching from attach-method "appliance" to "libvirt" has surprising side effects, so show a hint how to resolve the "authentication failed" error from libvirt. Patch is not compile tested.
src/libvirtdomain.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/src/libvirtdomain.c b/src/libvirtdomain.c index eecea26..110ee86 100644 --- a/src/libvirtdomain.c +++ b/src/libvirtdomain.c @@ -104,6 +104,8 @@ guestfs__add_domain (guestfs_h *g, const char *domain_name, err = virGetLastError (); error (g, _("could not connect to libvirt (code %d, domain %d): %s"), err->code, err->domain, err->message); + if (err->code == VIR_ERR_AUTH_FAILED) + error (g, _("Possible fix: 'polkit-auth --user <username> --grant org.libvirt.unix.manage'"));
Hmm, libguestfs is using the qemu://session instance of libvirt, of which one is launched per user. This should not require any authentication at all, since it is only accessible to the current user. PolicyKit is only relevant if connecting to the qemu:///system instance of libvirtd which runs privileged and this is not something libguestfs would be using, unless it was run as root. But if libguestfs ran as root, it would already have permission to connect via policykit. So I'm not really clear why you want this addition Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Wed, Oct 10, Daniel P. Berrange wrote:
On Wed, Oct 10, 2012 at 05:06:37PM +0200, Olaf Hering wrote:
+ if (err->code == VIR_ERR_AUTH_FAILED) + error (g, _("Possible fix: 'polkit-auth --user <username> --grant org.libvirt.unix.manage'"));
Hmm, libguestfs is using the qemu://session instance of libvirt, of which one is launched per user. This should not require any authentication at all, since it is only accessible to the current user. PolicyKit is only relevant if connecting to the qemu:///system instance of libvirtd which runs privileged and this is not something libguestfs would be using, unless it was run as root. But if libguestfs ran as root, it would already have permission to connect via policykit.
You are right, yesterday I was trying alot to get this working as non-root. The last version, before I came across polkit-auth, was virt-inspector -c qemu+ssh://localhost -v -d 6326ad4e-5805-2ab4-1338-d1dad8c76162 which gives the "authentication failed" error. But 'virsh list --all' returns an empty list, and every virt-* command just returns "Domain not found:" on my sles11sp2 system, which is not very helpful. Now I dont see a clean way how to catch that, other than putting it into some README. Are you saying that on Fedora or RHEL a user can launch libvirt domains without doing polkit-auth first? Olaf
On Wed, Oct 10, 2012 at 05:33:39PM +0200, Olaf Hering wrote:
On Wed, Oct 10, Daniel P. Berrange wrote:
On Wed, Oct 10, 2012 at 05:06:37PM +0200, Olaf Hering wrote:
+ if (err->code == VIR_ERR_AUTH_FAILED) + error (g, _("Possible fix: 'polkit-auth --user <username> --grant org.libvirt.unix.manage'"));
Hmm, libguestfs is using the qemu://session instance of libvirt, of which one is launched per user. This should not require any authentication at all, since it is only accessible to the current user. PolicyKit is only relevant if connecting to the qemu:///system instance of libvirtd which runs privileged and this is not something libguestfs would be using, unless it was run as root. But if libguestfs ran as root, it would already have permission to connect via policykit.
You are right, yesterday I was trying alot to get this working as non-root. The last version, before I came across polkit-auth, was virt-inspector -c qemu+ssh://localhost -v -d 6326ad4e-5805-2ab4-1338-d1dad8c76162 which gives the "authentication failed" error.
Because you used qemu+ssh here it will be trying & failing todo SSH authentication here. In addition your URI is invalid, so even if it got past the SSH auth, the connection would still fail.
But 'virsh list --all' returns an empty list, and every virt-* command just returns "Domain not found:" on my sles11sp2 system, which is not very helpful. Now I dont see a clean way how to catch that, other than putting it into some README.
Are you saying that on Fedora or RHEL a user can launch libvirt domains without doing polkit-auth first?
It depends on what instance of libvirtd you are connecting to. - The system instance, runs as root and requirs non-root users to auth with policykit - The session instance, runs as the same user id as the client app and does not require auth. Since libguestfs passes NULL for the URI, it will be connecting to the session instance if libguestfs is non-root and thus not require any auth. If libguestfs is run as root it will connect to the system instance which requires polkit auth, but root already has that granted. The only case where non-root needs polkit auth is if non-root is connecting to the system instance of libvirtd, but libguestfs choice of NULL uri means that should not happen. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Wed, Oct 10, Daniel P. Berrange wrote:
It depends on what instance of libvirtd you are connecting to.
- The system instance, runs as root and requirs non-root users to auth with policykit
- The session instance, runs as the same user id as the client app and does not require auth.
Since libguestfs passes NULL for the URI, it will be connecting to the session instance if libguestfs is non-root and thus not require any auth. If libguestfs is run as root it will connect to the system instance which requires polkit auth, but root already has that granted.
Thanks for that summary. Today I tried it with a openSuSE 12.2 system, which is more uptodate than a sles11sp2. Running libguestfs-test-tool fails because root starts a kvm guest, while a user starts a qemu guest. I think once the os type is correct for type 'qemu' it will work. Olaf olaf@stein-schneider:~> libguestfs-test-tool ************************************************************ * IMPORTANT NOTICE * * When reporting bugs, include the COMPLETE, UNEDITED * output below in your bug report. * ************************************************************ ===== Test starts here ===== PATH=/home/olaf/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games library version: 1.19.49 guestfs_get_append: (null) guestfs_get_attach_method: libvirt guestfs_get_autosync: 1 guestfs_get_direct: 0 guestfs_get_memsize: 500 guestfs_get_network: 0 guestfs_get_path: /usr/lib64/guestfs guestfs_get_pgroup: 0 guestfs_get_qemu: /usr/bin/qemu-kvm guestfs_get_recovery_proc: 1 guestfs_get_selinux: 0 guestfs_get_smp: 1 guestfs_get_trace: 0 guestfs_get_verbose: 1 host_cpu: x86_64 Launching appliance, timeout set to 600 seconds. libguestfs: libvirt version = 10002 libguestfs: [00000ms] connect to libvirt libguestfs: [00003ms] get libvirt capabilities libguestfs: [00048ms] build appliance libguestfs: [00048ms] create libvirt XML libguestfs: libvirt XML:\n<?xml version="1.0"?>\n<domain type="qemu" xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0">\n <name>guestfs-fs1ubzlxkfco2kz9</name>\n <memory unit="MiB">500</memory>\n <currentMemory unit="MiB">500</currentMemory>\n <cpu model="host-model"/>\n <vcpu>1</vcpu>\n <clock offset="utc"/>\n <os>\n <type>hvm</type>\n <kernel>/usr/lib64/guestfs/vmlinuz.x86_64</kernel>\n <initrd>/usr/lib64/guestfs/initramfs.x86_64.img</initrd>\n <cmdline>panic=1 console=ttyS0 udevtimeout=600 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=screen </cmdline>\n </os>\n <on_reboot>destroy</on_reboot>\n <devices>\n <controller type="scsi" index="0" model="virtio-scsi"/>\n <disk device="disk" type="file">\n <source file="/tmp/libguestfs-test-tool-sda-7iYTxF"/>\n <target dev="sda" bus="scsi"/>\n <driver name="qemu" type="raw" cache="none"/>\n <address type="drive" controller="0" bus="0" target="0" unit="0"/>\n </disk>\n <serial type="unix">\n <source mode="connect" path="/tmp/libguestfss1xgHv/console.sock"/>\n <target port="0"/>\n </serial>\n <channel type="unix">\n <source mode="connect" path="/tmp/libguestfss1xgHv/guestfsd.sock"/>\n <target type="virtio" name="org.libguestfs.channel.0"/>\n </channel>\n </devices>\n <qemu:commandline/>\n</domain>\n libguestfs: [00048ms] launch libvirt guest libguestfs: error: could not create appliance through libvirt: unknown OS type hvm [code=16 domain=20] libguestfs-test-tool: failed to launch appliance libguestfs: closing guestfs handle 0x1608ec0 (state 0) --- root 2012-10-11 12:50:54.000000000 +0200 +++ olaf 2012-10-11 12:51:15.000000000 +0200 @@ -1,7 +1,7 @@ libguestfs: libvirt XML: <?xml version="1.0"?> -<domain type="kvm" xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0"> - <name>guestfs-zftfuc2yqwc8qhyk</name> +<domain type="qemu" xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0"> + <name>guestfs-fs1ubzlxkfco2kz9</name> <memory unit="MiB">500</memory> <currentMemory unit="MiB">500</currentMemory> <cpu model="host-model"/> @@ -17,17 +17,17 @@ libguestfs: libvirt XML: <devices> <controller type="scsi" index="0" model="virtio-scsi"/> <disk device="disk" type="file"> - <source file="/tmp/libguestfs-test-tool-sda-uzaB2z"/> + <source file="/tmp/libguestfs-test-tool-sda-7iYTxF"/> <target dev="sda" bus="scsi"/> <driver name="qemu" type="raw" cache="none"/> <address type="drive" controller="0" bus="0" target="0" unit="0"/> </disk> <serial type="unix"> - <source mode="connect" path="/tmp/libguestfs3kAQMc/console.sock"/> + <source mode="connect" path="/tmp/libguestfss1xgHv/console.sock"/> <target port="0"/> </serial> <channel type="unix"> - <source mode="connect" path="/tmp/libguestfs3kAQMc/guestfsd.sock"/> + <source mode="connect" path="/tmp/libguestfss1xgHv/guestfsd.sock"/> <target type="virtio" name="org.libguestfs.channel.0"/> </channel> </devices>
On Thu, Oct 11, 2012 at 12:57:12PM +0200, Olaf Hering wrote:
On Wed, Oct 10, Daniel P. Berrange wrote:
It depends on what instance of libvirtd you are connecting to.
- The system instance, runs as root and requirs non-root users to auth with policykit
- The session instance, runs as the same user id as the client app and does not require auth.
Since libguestfs passes NULL for the URI, it will be connecting to the session instance if libguestfs is non-root and thus not require any auth. If libguestfs is run as root it will connect to the system instance which requires polkit auth, but root already has that granted.
Thanks for that summary.
Today I tried it with a openSuSE 12.2 system, which is more uptodate than a sles11sp2. Running libguestfs-test-tool fails because root starts a kvm guest, while a user starts a qemu guest. I think once the os type is correct for type 'qemu' it will work.
Hmm, on Fedora non-root is able to use KVM just fine. If you have a new enough libvirt, you should have a 'virt-host-validate' command. Can you run that as both root and non-root and provide the output for each case. Also provide the 'virsh -c qemu:///session capabilities' output when run as non-root Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Thu, Oct 11, Daniel P. Berrange wrote:
Hmm, on Fedora non-root is able to use KVM just fine. If you have a new enough libvirt, you should have a 'virt-host-validate' command. Can you run that as both root and non-root and provide the output for each case.
The issue is that a user is not automatically in the kvm group, which however does not prevent a successful run of 'LIBGUESTFS_ATTACH_METHOD=appliance libguestfs-test-tool'. root@stein-schneider:~ # virt-host-validate QEMU: Checking for hardware virtualization : PASS QEMU: Checking for device /dev/kvm : PASS QEMU: Checking for device /dev/vhost-net : PASS QEMU: Checking for device /dev/net/tun : PASS LXC: Checking for Linux >= 2.6.26 : PASS olaf@stein-schneider:~> virt-host-validate QEMU: Checking for hardware virtualization : PASS QEMU: Checking for device /dev/kvm : FAIL (Check that the 'kvm-intel' or 'kvm-amd' modules are loaded & the BIOS has enabled virtualization) QEMU: Checking for device /dev/vhost-net : WARN (Load the 'vhost_net' module to improve performance of virtio networking) QEMU: Checking for device /dev/net/tun : PASS LXC: Checking for Linux >= 2.6.26 : PASS olaf@stein-schneider:~> l /dev/kvm crw-rw---- 1 root kvm 10, 232 Okt 11 12:37 /dev/kvm olaf@stein-schneider:~> id uid=1000(olaf) gid=100(users) groups=100(users),33(video) However, adding 'olaf' into group 'kvm' does not help to run libguestfs-test-tool, its still a 'qemu' guest. olaf@stein-schneider:~> virsh -c qemu:///session capabilities <capabilities> <host> <uuid>30826d35-f748-ac09-3792-1386d0a79891</uuid> <cpu> <arch>x86_64</arch> <model>Nehalem</model> <vendor>Intel</vendor> <topology sockets='1' cores='4' threads='2'/> <feature name='rdtscp'/> <feature name='dca'/> <feature name='pdcm'/> <feature name='xtpr'/> <feature name='tm2'/> <feature name='est'/> <feature name='vmx'/> <feature name='ds_cpl'/> <feature name='monitor'/> <feature name='dtes64'/> <feature name='pbe'/> <feature name='tm'/> <feature name='ht'/> <feature name='ss'/> <feature name='acpi'/> <feature name='ds'/> <feature name='vme'/> </cpu> <power_management> <suspend_disk/> </power_management> <migration_features> <live/> <uri_transports> <uri_transport>tcp</uri_transport> </uri_transports> </migration_features> <topology> <cells num='1'> <cell id='0'> <cpus num='8'> <cpu id='0'/> <cpu id='1'/> <cpu id='2'/> <cpu id='3'/> <cpu id='4'/> <cpu id='5'/> <cpu id='6'/> <cpu id='7'/> </cpus> </cell> </cells> </topology> <secmodel> <model>none</model> <doi>0</doi> </secmodel> </host> </capabilities> Olaf
On Thu, Oct 11, 2012 at 01:10:16PM +0200, Olaf Hering wrote:
olaf@stein-schneider:~> l /dev/kvm crw-rw---- 1 root kvm 10, 232 Okt 11 12:37 /dev/kvm
Ok, so suse has restricted permissions :-(
olaf@stein-schneider:~> id uid=1000(olaf) gid=100(users) groups=100(users),33(video)
However, adding 'olaf' into group 'kvm' does not help to run libguestfs-test-tool, its still a 'qemu' guest.
Did you login + logout and restart libvirtd after adding yourself to the kvm group ?
olaf@stein-schneider:~> virsh -c qemu:///session capabilities <capabilities>
<host> <uuid>30826d35-f748-ac09-3792-1386d0a79891</uuid> <cpu> <arch>x86_64</arch> <model>Nehalem</model> <vendor>Intel</vendor> <topology sockets='1' cores='4' threads='2'/> <feature name='rdtscp'/> <feature name='dca'/> <feature name='pdcm'/> <feature name='xtpr'/> <feature name='tm2'/> <feature name='est'/> <feature name='vmx'/> <feature name='ds_cpl'/> <feature name='monitor'/> <feature name='dtes64'/> <feature name='pbe'/> <feature name='tm'/> <feature name='ht'/> <feature name='ss'/> <feature name='acpi'/> <feature name='ds'/> <feature name='vme'/> </cpu> <power_management> <suspend_disk/> </power_management> <migration_features> <live/> <uri_transports> <uri_transport>tcp</uri_transport> </uri_transports> </migration_features> <topology> <cells num='1'> <cell id='0'> <cpus num='8'> <cpu id='0'/> <cpu id='1'/> <cpu id='2'/> <cpu id='3'/> <cpu id='4'/> <cpu id='5'/> <cpu id='6'/> <cpu id='7'/> </cpus> </cell> </cells> </topology> <secmodel> <model>none</model> <doi>0</doi> </secmodel> </host>
</capabilities>
This is peculiar - it doesn't show any QEMU guests at all. What does 'virsh -c qemu:///system capabilities' report ? Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Thu, Oct 11, Daniel P. Berrange wrote:
On Thu, Oct 11, 2012 at 01:10:16PM +0200, Olaf Hering wrote:
However, adding 'olaf' into group 'kvm' does not help to run libguestfs-test-tool, its still a 'qemu' guest. Did you login + logout and restart libvirtd after adding yourself to the kvm group ?
Yes, id shows the new group.
This is peculiar - it doesn't show any QEMU guests at all. What does 'virsh -c qemu:///system capabilities' report ?
I think a user has not enough permissions per default. root@stein-schneider:~ # virsh -c qemu:///system capabilities <capabilities> <host> <uuid>1269ce01-fe8f-11d5-90fd-00265523ecea</uuid> <cpu> <arch>x86_64</arch> <model>Nehalem</model> <vendor>Intel</vendor> <topology sockets='1' cores='4' threads='2'/> <feature name='rdtscp'/> <feature name='dca'/> <feature name='pdcm'/> <feature name='xtpr'/> <feature name='tm2'/> <feature name='est'/> <feature name='vmx'/> <feature name='ds_cpl'/> <feature name='monitor'/> <feature name='dtes64'/> <feature name='pbe'/> <feature name='tm'/> <feature name='ht'/> <feature name='ss'/> <feature name='acpi'/> <feature name='ds'/> <feature name='vme'/> </cpu> <power_management> <suspend_disk/> </power_management> <migration_features> <live/> <uri_transports> <uri_transport>tcp</uri_transport> </uri_transports> </migration_features> <topology> <cells num='1'> <cell id='0'> <cpus num='8'> <cpu id='0'/> <cpu id='1'/> <cpu id='2'/> <cpu id='3'/> <cpu id='4'/> <cpu id='5'/> <cpu id='6'/> <cpu id='7'/> </cpus> </cell> </cells> </topology> <secmodel> <model>none</model> <doi>0</doi> </secmodel> <secmodel> <model>dac</model> <doi>0</doi> </secmodel> </host> <guest> <os_type>hvm</os_type> <arch name='i686'> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-kvm</emulator> <machine>pc-1.1</machine> <machine canonical='pc-1.1'>pc</machine> <machine>pc-1.0</machine> <machine>pc-0.15</machine> <machine>pc-0.14</machine> <machine>pc-0.13</machine> <machine>pc-0.12</machine> <machine>pc-0.11</machine> <machine>pc-0.10</machine> <machine>isapc</machine> <domain type='qemu'> </domain> <domain type='kvm'> <emulator>/usr/bin/qemu-kvm</emulator> </domain> </arch> <features> <cpuselection/> <deviceboot/> <pae/> <nonpae/> <acpi default='on' toggle='yes'/> <apic default='on' toggle='no'/> </features> </guest> <guest> <os_type>hvm</os_type> <arch name='x86_64'> <wordsize>64</wordsize> <emulator>/usr/bin/qemu-kvm</emulator> <machine>pc-1.1</machine> <machine canonical='pc-1.1'>pc</machine> <machine>pc-1.0</machine> <machine>pc-0.15</machine> <machine>pc-0.14</machine> <machine>pc-0.13</machine> <machine>pc-0.12</machine> <machine>pc-0.11</machine> <machine>pc-0.10</machine> <machine>isapc</machine> <domain type='qemu'> </domain> <domain type='kvm'> <emulator>/usr/bin/qemu-kvm</emulator> </domain> </arch> <features> <cpuselection/> <deviceboot/> <acpi default='on' toggle='yes'/> <apic default='on' toggle='no'/> </features> </guest> </capabilities> Olaf
On Thu, Oct 11, Olaf Hering wrote:
On Thu, Oct 11, Daniel P. Berrange wrote:
On Thu, Oct 11, 2012 at 01:10:16PM +0200, Olaf Hering wrote:
However, adding 'olaf' into group 'kvm' does not help to run libguestfs-test-tool, its still a 'qemu' guest. Did you login + logout and restart libvirtd after adding yourself to the kvm group ?
Yes, id shows the new group.
After some more testing with a new user it finally works if the given user is in group 'kvm'. I made these user changes with yast, appearently there is some syncing going on in the background. nscd does not run. No idea why it initially failed for user 'olaf'. So for short: its now working for me with 12.2, and 'virsh -c qemu:///session capabilities' prints also os_type hvm. Olaf
On Thu, Oct 11, 2012 at 01:17:37PM +0200, Olaf Hering wrote:
On Thu, Oct 11, Daniel P. Berrange wrote:
On Thu, Oct 11, 2012 at 01:10:16PM +0200, Olaf Hering wrote:
However, adding 'olaf' into group 'kvm' does not help to run libguestfs-test-tool, its still a 'qemu' guest. Did you login + logout and restart libvirtd after adding yourself to the kvm group ?
Yes, id shows the new group.
This is peculiar - it doesn't show any QEMU guests at all. What does 'virsh -c qemu:///system capabilities' report ?
I think a user has not enough permissions per default.
root@stein-schneider:~ # virsh -c qemu:///system capabilities <capabilities>
<host> <uuid>1269ce01-fe8f-11d5-90fd-00265523ecea</uuid> <cpu> <arch>x86_64</arch> <model>Nehalem</model> <vendor>Intel</vendor> <topology sockets='1' cores='4' threads='2'/> <feature name='rdtscp'/> <feature name='dca'/> <feature name='pdcm'/> <feature name='xtpr'/> <feature name='tm2'/> <feature name='est'/> <feature name='vmx'/> <feature name='ds_cpl'/> <feature name='monitor'/> <feature name='dtes64'/> <feature name='pbe'/> <feature name='tm'/> <feature name='ht'/> <feature name='ss'/> <feature name='acpi'/> <feature name='ds'/> <feature name='vme'/> </cpu> <power_management> <suspend_disk/> </power_management> <migration_features> <live/> <uri_transports> <uri_transport>tcp</uri_transport> </uri_transports> </migration_features> <topology> <cells num='1'> <cell id='0'> <cpus num='8'> <cpu id='0'/> <cpu id='1'/> <cpu id='2'/> <cpu id='3'/> <cpu id='4'/> <cpu id='5'/> <cpu id='6'/> <cpu id='7'/> </cpus> </cell> </cells> </topology> <secmodel> <model>none</model> <doi>0</doi> </secmodel> <secmodel> <model>dac</model> <doi>0</doi> </secmodel> </host>
<guest> <os_type>hvm</os_type> <arch name='i686'> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-kvm</emulator> <machine>pc-1.1</machine> <machine canonical='pc-1.1'>pc</machine> <machine>pc-1.0</machine> <machine>pc-0.15</machine> <machine>pc-0.14</machine> <machine>pc-0.13</machine> <machine>pc-0.12</machine> <machine>pc-0.11</machine> <machine>pc-0.10</machine> <machine>isapc</machine> <domain type='qemu'> </domain> <domain type='kvm'> <emulator>/usr/bin/qemu-kvm</emulator> </domain> </arch> <features> <cpuselection/> <deviceboot/> <pae/> <nonpae/> <acpi default='on' toggle='yes'/> <apic default='on' toggle='no'/> </features> </guest>
<guest> <os_type>hvm</os_type> <arch name='x86_64'> <wordsize>64</wordsize> <emulator>/usr/bin/qemu-kvm</emulator> <machine>pc-1.1</machine> <machine canonical='pc-1.1'>pc</machine> <machine>pc-1.0</machine> <machine>pc-0.15</machine> <machine>pc-0.14</machine> <machine>pc-0.13</machine> <machine>pc-0.12</machine> <machine>pc-0.11</machine> <machine>pc-0.10</machine> <machine>isapc</machine> <domain type='qemu'> </domain> <domain type='kvm'> <emulator>/usr/bin/qemu-kvm</emulator> </domain> </arch> <features> <cpuselection/> <deviceboot/> <acpi default='on' toggle='yes'/> <apic default='on' toggle='no'/> </features> </guest>
</capabilities>
Ah interesting. So this machine only has the qemu-kvm binary installed, none of the other non-KVM binaries. What is the version of libvirt that you have ? Until fairly recently libvirt would not detect the fact that /usr/bin/qemu-kvm was able to support non-KVM modes, which could be causing some of the pain here. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Thu, Oct 11, Daniel P. Berrange wrote:
Ah interesting. So this machine only has the qemu-kvm binary installed, none of the other non-KVM binaries.
What is the version of libvirt that you have ? Until fairly recently libvirt would not detect the fact that /usr/bin/qemu-kvm was able to support non-KVM modes, which could be causing some of the pain here.
Its 0.10.2, which is what libguestfs expects at runtime. Olaf
On Thu, Oct 11, 2012 at 03:31:12PM +0200, Olaf Hering wrote:
On Thu, Oct 11, Daniel P. Berrange wrote:
Ah interesting. So this machine only has the qemu-kvm binary installed, none of the other non-KVM binaries.
What is the version of libvirt that you have ? Until fairly recently libvirt would not detect the fact that /usr/bin/qemu-kvm was able to support non-KVM modes, which could be causing some of the pain here.
Its 0.10.2, which is what libguestfs expects at runtime.
Actually we also need some post-0.10.2 patches. 0001-command-Move-environ-adding-code-to-common-function-.patch 0002-command-Change-virCommandAddEnv-so-it-replaces-exist.patch from here: http://pkgs.fedoraproject.org/cgit/libvirt.git/tree/ (And likely even more in the near future as we fix SELinux support and add support for remote). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/
On Thu, Oct 11, 2012 at 01:10:16PM +0200, Olaf Hering wrote:
However, adding 'olaf' into group 'kvm' does not help to run libguestfs-test-tool, its still a 'qemu' guest.
libguestfs-test-tool just tests the library. In the library (src/launch-libvirt.c) we use a hack to detect if kvm is supported: /* Big hack, instead of actually parsing the capabilities XML (XXX). */ type = strstr (capabilities_xml, "'kvm'") != NULL ? "kvm" : "qemu"; and 'type' is directly used in the <domain type=...> field in the XML. FWIW I see that the substring "'kvm'" does not appear in the capabilities XML you pasted. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org
On Wed, Oct 10, 2012 at 04:16:21PM +0100, Daniel P. Berrange wrote:
On Wed, Oct 10, 2012 at 05:06:37PM +0200, Olaf Hering wrote:
Signed-off-by: Olaf Hering <olaf@aepfle.de> ---
Switching from attach-method "appliance" to "libvirt" has surprising side effects, so show a hint how to resolve the "authentication failed" error from libvirt. Patch is not compile tested.
src/libvirtdomain.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/src/libvirtdomain.c b/src/libvirtdomain.c index eecea26..110ee86 100644 --- a/src/libvirtdomain.c +++ b/src/libvirtdomain.c @@ -104,6 +104,8 @@ guestfs__add_domain (guestfs_h *g, const char *domain_name, err = virGetLastError (); error (g, _("could not connect to libvirt (code %d, domain %d): %s"), err->code, err->domain, err->message); + if (err->code == VIR_ERR_AUTH_FAILED) + error (g, _("Possible fix: 'polkit-auth --user <username> --grant org.libvirt.unix.manage'"));
Hmm, libguestfs is using the qemu://session instance of libvirt, of which one is launched per user. This should not require any authentication at all, since it is only accessible to the current user. PolicyKit is only relevant if connecting to the qemu:///system instance of libvirtd which runs privileged and this is not something libguestfs would be using, unless it was run as root. But if libguestfs ran as root, it would already have permission to connect via policykit.
I don't think this is true. libguestfs use of libvirt is a bit of a mess at the moment, since we end up opening two connections if you use the -d option ... this is something I'm intending to fix. Nevertheless, it should be using NULL everywhere, so depending on whether you run it as root or not, it will use qemu:///system or qemu:///session. It's somewhere on the to-do list to: (1) Fix the utilities so they only need to open one connection (this will matter in the remote case). (2) Support authentication in libvirt by mapping libvirt auth callbacks to libguestfs events. Rich.
So I'm not really clear why you want this addition
Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
_______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org
On Wed, Oct 10, 2012 at 04:38:19PM +0100, Richard W.M. Jones wrote:
On Wed, Oct 10, 2012 at 04:16:21PM +0100, Daniel P. Berrange wrote:
On Wed, Oct 10, 2012 at 05:06:37PM +0200, Olaf Hering wrote:
Signed-off-by: Olaf Hering <olaf@aepfle.de> ---
Switching from attach-method "appliance" to "libvirt" has surprising side effects, so show a hint how to resolve the "authentication failed" error from libvirt. Patch is not compile tested.
src/libvirtdomain.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/src/libvirtdomain.c b/src/libvirtdomain.c index eecea26..110ee86 100644 --- a/src/libvirtdomain.c +++ b/src/libvirtdomain.c @@ -104,6 +104,8 @@ guestfs__add_domain (guestfs_h *g, const char *domain_name, err = virGetLastError (); error (g, _("could not connect to libvirt (code %d, domain %d): %s"), err->code, err->domain, err->message); + if (err->code == VIR_ERR_AUTH_FAILED) + error (g, _("Possible fix: 'polkit-auth --user <username> --grant org.libvirt.unix.manage'"));
Hmm, libguestfs is using the qemu://session instance of libvirt, of which one is launched per user. This should not require any authentication at all, since it is only accessible to the current user. PolicyKit is only relevant if connecting to the qemu:///system instance of libvirtd which runs privileged and this is not something libguestfs would be using, unless it was run as root. But if libguestfs ran as root, it would already have permission to connect via policykit.
I don't think this is true.
libguestfs use of libvirt is a bit of a mess at the moment, since we end up opening two connections if you use the -d option ... this is something I'm intending to fix.
Nevertheless, it should be using NULL everywhere, so depending on whether you run it as root or not, it will use qemu:///system or qemu:///session.
But in neither of those scenarios would policykit auth be required. The qemu:///session instance will never need auth. The qemu:///system uses polkit by default, but since you're root in this usage, it will not need any more polkit rules. The only time you'd need auth is if the system instance had been configured to use SASL, and there was a username/password set, in which case the proposed error message won't be relevant.
It's somewhere on the to-do list to:
(1) Fix the utilities so they only need to open one connection (this will matter in the remote case).
(2) Support authentication in libvirt by mapping libvirt auth callbacks to libguestfs events.
Makes sense, but I think that's unrelated to what's going in this proposed patch. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Wed, Oct 10, 2012 at 04:38:19PM +0100, Richard W.M. Jones wrote:
end up opening two connections if you use the -d option ... this is
By the way, I mean the -c and/or -d options. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v
On Wed, Oct 10, Richard W.M. Jones wrote:
libguestfs use of libvirt is a bit of a mess at the moment, since we end up opening two connections if you use the -d option ... this is something I'm intending to fix.
Nevertheless, it should be using NULL everywhere, so depending on whether you run it as root or not, it will use qemu:///system or qemu:///session.
It's somewhere on the to-do list to:
(1) Fix the utilities so they only need to open one connection (this will matter in the remote case).
(2) Support authentication in libvirt by mapping libvirt auth callbacks to libguestfs events.
Is this the reason why the first command fails, but the others work ok for me? virt-filesystems -v -c qemu+ssh:///system -d sles11sp2 --all --long virt-rescue -v -c qemu+ssh:///system -d opensuse12 -r virsh -c qemu+ssh:///system list --all Olaf
On Fri, Oct 12, 2012 at 04:20:50PM +0200, Olaf Hering wrote:
On Wed, Oct 10, Richard W.M. Jones wrote:
libguestfs use of libvirt is a bit of a mess at the moment, since we end up opening two connections if you use the -d option ... this is something I'm intending to fix.
Nevertheless, it should be using NULL everywhere, so depending on whether you run it as root or not, it will use qemu:///system or qemu:///session.
It's somewhere on the to-do list to:
(1) Fix the utilities so they only need to open one connection (this will matter in the remote case).
(2) Support authentication in libvirt by mapping libvirt auth callbacks to libguestfs events.
Is this the reason why the first command fails, but the others work ok for me?
virt-filesystems -v -c qemu+ssh:///system -d sles11sp2 --all --long
virt-rescue -v -c qemu+ssh:///system -d opensuse12 -r virsh -c qemu+ssh:///system list --all
virt-rescue doesn't use the libvirt backend. See: https://github.com/libguestfs/libguestfs/commit/2e36adf83ce4a9cbccd313d6f3a8... This is just a shortcoming of the libvirt backend, albeit a complicated one to fix. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
On Fri, Oct 12, Richard W.M. Jones wrote:
On Fri, Oct 12, 2012 at 04:20:50PM +0200, Olaf Hering wrote:
On Wed, Oct 10, Richard W.M. Jones wrote:
libguestfs use of libvirt is a bit of a mess at the moment, since we end up opening two connections if you use the -d option ... this is something I'm intending to fix.
Nevertheless, it should be using NULL everywhere, so depending on whether you run it as root or not, it will use qemu:///system or qemu:///session.
It's somewhere on the to-do list to:
(1) Fix the utilities so they only need to open one connection (this will matter in the remote case).
(2) Support authentication in libvirt by mapping libvirt auth callbacks to libguestfs events.
Is this the reason why the first command fails, but the others work ok for me?
virt-filesystems -v -c qemu+ssh:///system -d sles11sp2 --all --long
virt-rescue -v -c qemu+ssh:///system -d opensuse12 -r virsh -c qemu+ssh:///system list --all
virt-rescue doesn't use the libvirt backend. See:
It gets the list of configured devices from libvirt at least. The message it prints is clear about what you said: ... virt-rescue: warning: virt-rescue doesn't work with the libvirt backend at the moment. As a workaround, forcing attach-method = 'appliance'. ... Olaf
On Fri, Oct 12, 2012 at 05:01:04PM +0200, Olaf Hering wrote:
On Fri, Oct 12, Richard W.M. Jones wrote:
On Fri, Oct 12, 2012 at 04:20:50PM +0200, Olaf Hering wrote:
On Wed, Oct 10, Richard W.M. Jones wrote:
libguestfs use of libvirt is a bit of a mess at the moment, since we end up opening two connections if you use the -d option ... this is something I'm intending to fix.
Nevertheless, it should be using NULL everywhere, so depending on whether you run it as root or not, it will use qemu:///system or qemu:///session.
It's somewhere on the to-do list to:
(1) Fix the utilities so they only need to open one connection (this will matter in the remote case).
(2) Support authentication in libvirt by mapping libvirt auth callbacks to libguestfs events.
Is this the reason why the first command fails, but the others work ok for me?
virt-filesystems -v -c qemu+ssh:///system -d sles11sp2 --all --long
virt-rescue -v -c qemu+ssh:///system -d opensuse12 -r virsh -c qemu+ssh:///system list --all
virt-rescue doesn't use the libvirt backend. See:
It gets the list of configured devices from libvirt at least. The message it prints is clear about what you said:
... virt-rescue: warning: virt-rescue doesn't work with the libvirt backend at the moment. As a workaround, forcing attach-method = 'appliance'. ...
Right ... that comes down to the two connection thing (item (1) above). What should happen is that the virt tool opens one connection to libvirt, and then passes it along to libguestfs so it can use it to create the transient appliance. In fact, this will not just be desirable, but very necessary once we enable libvirt remote support, or use libvirt authentication in any non-trivial manner. In detail: Up to 3 libvirt connections can be opened: (i) virt-alignment-scan and virt-df have a way that you can scan all domains, and in this case they get the list from libvirt by opening a connection (align/domains.c, df/domains.c). (ii) The -c/-d options call guestfs_add_domain, which opens a libvirt connection in order to resolve the libvirt domain name into a list of disks (src/libvirtdomain.c). (iii) If the backend is libvirt, then we use libvirt to create the appliance. This involves another libvirt connection which is created entirely inside the libvirt backend (src/launch-libvirt.c). If we change things so the virt tool manages the libvirt connection, the tool could pass it to a new API that libguestfs would be able to use for guestfs_add_domain (ii) and/or the libvirt backend (iii), as well as using it itself for listing domains (i). There are three complicated bits to this, which is why I haven't just gone ahead and implemented it yet: (a) You might want to list domains from another (non-qemu) hypervisor, but in general you'd always want to use qemu to create the transient appliance. This argues for a way to have up to two libvirt connections, but that becomes complex to implement. (b) It's hard to pass virConnectPtr / virDomainPtr to libguestfs functions, because there is no simple way to implement that passing in any language binding other than C. Dan and I have discussed this a bit but didn't come up with any good ideas. (c) Existing backwards compat constraints: guestfs_add_domain takes an optional 'libvirturi' parameter; the attach-method also has an optional libvirt URI (ie. "libvirt:<URI>"). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org
participants (3)
-
Daniel P. Berrange -
Olaf Hering -
Richard W.M. Jones