10:06 a.m.
Signed-off-by: Olaf Hering <olaf(a)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
10:16 a.m.
On Wed, Oct 10, 2012 at 05:06:37PM +0200, Olaf Hering wrote:
Signed-off-by: Olaf Hering <olaf(a)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 :|
10:33 a.m.
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
10:48 a.m.
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 :|
5:57 a.m.
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>
6 a.m.
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 :|
6:10 a.m.
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
6:13 a.m.
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 :|
6:17 a.m.
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
8:22 a.m.
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
8:26 a.m.
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 :|
8:31 a.m.
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
8:41 a.m.
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/
6:54 a.m.
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
10:38 a.m.
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(a)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(a)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
10:44 a.m.
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(a)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 :|
10:48 a.m.
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
9:20 a.m.
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
9:58 a.m.
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/2e36adf83ce4a9cbccd313d6f...
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
10:01 a.m.
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
10:27 a.m.
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
4305
days inactive
4307
days old
20 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Olaf Hering -
Richard W.M. Jones