Re: [Libvirt] VNC auth per VM
Daniel P. Berrange wrote: On Mon, Jun 08, 2009 at 11:35:00AM +0200, Christian Weyermann wrote: Hello everybody, I encountered the following problem. I want my users to only be able to connect to their own virtual machines via VNC. Is there any way to do so? The VNC authentication setup is currently being done per-host, so there is no way to define ACLs per-(user,vm) tuple as you describe. What about the VNC password? That's per-VM, isn't it? -jim -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvirt] VNC auth per VM
On Thu, Jun 11, 2009 at 04:05:39AM -0400, Jim Paris wrote: Daniel P. Berrange wrote: On Mon, Jun 08, 2009 at 11:35:00AM +0200, Christian Weyermann wrote: Hello everybody, I encountered the following problem. I want my users to only be able to connect to their own virtual machines via VNC. Is there any way to do so? The VNC authentication setup is currently being done per-host, so there is no way to define ACLs per-(user,vm) tuple as you describe. What about the VNC password? That's per-VM, isn't it? That is true by I don't really consider VNC password to be useful. It is utterly insecure. If you want to have plain passwords, then its better to use the new SASL authentication method, with its Digest-MD5 plugin. That is still not top-grade security, but it is better then VNC password and allows configuration of arbitrary Username+pasword pairs.. At which point we just need ACLs against the usernames. SASL also provide Kerberos auth, where we can do an ACL against the Kerberos principle name. And VeNCrypt provides TLS+x509 certificates which you can either layer SASL over again, or require client x509 certs and do an ACL against the client CNAME. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvirt] VNC auth per VM
On Thu, Jun 11, 2009 at 04:05:39AM -0400, Jim Paris wrote: Daniel P. Berrange wrote: On Mon, Jun 08, 2009 at 11:35:00AM +0200, Christian Weyermann wrote: Hello everybody, I encountered the following problem. I want my users to only be able to connect to their own virtual machines via VNC. Is there any way to do so? The VNC authentication setup is currently being done per-host, so there is no way to define ACLs per-(user,vm) tuple as you describe. What about the VNC password? That's per-VM, isn't it? With KVM/QEMU, you can set a VNC password per VM. But I think it is either/or though; you can use VNC with passwords (no encryption), or use VNC with TLS, which is encrypted, but anyone with a valid certificate can connect (to any VM). Someone correct me if I'm wrong on that. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] getFreeMemory reporting incorrectly?
On Wed, Jun 10, 2009 at 07:28:51PM -0400, Hany Fahim wrote: Hey Daniel, Here is the output of 'xm list' from both machines: I wanted the 'xm info' output actually Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvirt] VNC auth per VM
Daniel P. Berrange wrote: What about the VNC password? That's per-VM, isn't it? That is true by I don't really consider VNC password to be useful. It is utterly insecure. ... Garry Dolley wrote: With KVM/QEMU, you can set a VNC password per VM. But I think it is either/or though; you can use VNC with passwords (no encryption), or use VNC with TLS, which is encrypted, but anyone with a valid certificate can connect (to any VM). Ok, makes sense. In my own case, where VNC only listens on 127.0.0.1 and all remote connections are tunneled through SSH anyway, I think that plaintext passwords and the lack of VNC encryption would be OK. Thanks for the clearifications. -jim -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvirt] VNC auth per VM
Daniel P. Berrange schrieb: On Thu, Jun 11, 2009 at 04:05:39AM -0400, Jim Paris wrote: Daniel P. Berrange wrote: On Mon, Jun 08, 2009 at 11:35:00AM +0200, Christian Weyermann wrote: Hello everybody, I encountered the following problem. I want my users to only be able to connect to their own virtual machines via VNC. Is there any way to do so? The VNC authentication setup is currently being done per-host, so there is no way to define ACLs per-(user,vm) tuple as you describe. What about the VNC password? That's per-VM, isn't it? That is true by I don't really consider VNC password to be useful. It is utterly insecure. If you want to have plain passwords, then its better to use the new SASL authentication method, with its Digest-MD5 plugin. That is still not top-grade security, but it is better then VNC password and allows configuration of arbitrary Username+pasword pairs.. At which point we just need ACLs against the usernames. SASL also provide Kerberos auth, where we can do an ACL against the Kerberos principle name. And VeNCrypt provides TLS+x509 certificates which you can either layer SASL over again, or require client x509 certs and do an ACL against the client CNAME Ok, so let me sumarize: It is possible to define username+password pairs via SASL. SASL can also sync with Kerberos. So the only problem left is, that there is no way to assign a specific username to a VM. So, what we need is a plugin, where we have an username and a virtual machine as input and we need to refuse the connection, if this pair is not valid. The VNC Server is part of libvirt, so the perfect method to add this functionallity would be the VNC Servers authenticate or start method. However, a Windows user is still not able to connect as there is no windows vnc client capable of doing SASL. Kind Regards, Chris -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvirt] VNC auth per VM
On Thu, Jun 11, 2009 at 11:10:47AM +0200, Christian Weyermann wrote: Daniel P. Berrange schrieb: On Thu, Jun 11, 2009 at 04:05:39AM -0400, Jim Paris wrote: Daniel P. Berrange wrote: On Mon, Jun 08, 2009 at 11:35:00AM +0200, Christian Weyermann wrote: Hello everybody, I encountered the following problem. I want my users to only be able to connect to their own virtual machines via VNC. Is there any way to do so? The VNC authentication setup is currently being done per-host, so there is no way to define ACLs per-(user,vm) tuple as you describe. What about the VNC password? That's per-VM, isn't it? That is true by I don't really consider VNC password to be useful. It is utterly insecure. If you want to have plain passwords, then its better to use the new SASL authentication method, with its Digest-MD5 plugin. That is still not top-grade security, but it is better then VNC password and allows configuration of arbitrary Username+pasword pairs.. At which point we just need ACLs against the usernames. SASL also provide Kerberos auth, where we can do an ACL against the Kerberos principle name. And VeNCrypt provides TLS+x509 certificates which you can either layer SASL over again, or require client x509 certs and do an ACL against the client CNAME Ok, so let me sumarize: It is possible to define username+password pairs via SASL. SASL can also sync with Kerberos. So the only problem left is, that there is no way to assign a specific username to a VM. So, what we need is a plugin, where we have an username and a virtual machine as input and we need to refuse the connection, if this pair is not valid. The VNC Server is part of libvirt, so the perfect method to add this functionallity would be the VNC Servers authenticate or start method. However, a Windows user is still not able to connect as there is no windows vnc client capable of doing SASL. GTK-VNC builds on Windows, and so does libvirt. So the intent was that we'd be able to have virt-viewer working on Windows using those two. Oh, when I say Windows, i mean Mingw32 Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvirt] VNC auth per VM
Daniel P. Berrange schrieb: On Thu, Jun 11, 2009 at 11:10:47AM +0200, Christian Weyermann wrote: Daniel P. Berrange schrieb: On Thu, Jun 11, 2009 at 04:05:39AM -0400, Jim Paris wrote: Daniel P. Berrange wrote: On Mon, Jun 08, 2009 at 11:35:00AM +0200, Christian Weyermann wrote: Hello everybody, I encountered the following problem. I want my users to only be able to connect to their own virtual machines via VNC. Is there any way to do so? The VNC authentication setup is currently being done per-host, so there is no way to define ACLs per-(user,vm) tuple as you describe. What about the VNC password? That's per-VM, isn't it? That is true by I don't really consider VNC password to be useful. It is utterly insecure. If you want to have plain passwords, then its better to use the new SASL authentication method, with its Digest-MD5 plugin. That is still not top-grade security, but it is better then VNC password and allows configuration of arbitrary Username+pasword pairs.. At which point we just need ACLs against the usernames. SASL also provide Kerberos auth, where we can do an ACL against the Kerberos principle name. And VeNCrypt provides TLS+x509 certificates which you can either layer SASL over again, or require client x509 certs and do an ACL against the client CNAME Ok, so let me sumarize: It is possible to define username+password pairs via SASL. SASL can also sync with Kerberos. So the only problem left is, that there is no way to assign a specific username to a VM. So, what we need is a plugin, where we have an username and a virtual machine as input and we need to refuse the connection, if this pair is not valid. The VNC Server is part of libvirt, so the perfect method to add this functionallity would be the VNC Servers authenticate or start method. However, a Windows user is still not able to connect as there is no windows vnc client capable of doing SASL. GTK-VNC builds on Windows, and so does libvirt. So the intent was that we'd be able to have virt-viewer working on Windows using those two. Oh, when I say Windows, i mean Mingw32 Ok, so the other part of the post is correct? So what do you think about the effort for implementing this feature? -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvirt] VNC auth per VM
Daniel P. Berrange schrieb: On Thu, Jun 11, 2009 at 11:45:43AM +0200, Christian Weyermann wrote: Daniel P. Berrange schrieb: On Thu, Jun 11, 2009 at 11:10:47AM +0200, Christian Weyermann wrote: Daniel P. Berrange schrieb: On Thu, Jun 11, 2009 at 04:05:39AM -0400, Jim Paris wrote: Daniel P. Berrange wrote: On Mon, Jun 08, 2009 at 11:35:00AM +0200, Christian Weyermann wrote: Hello everybody, I encountered the following problem. I want my users to only be able to connect to their own virtual machines via VNC. Is there any way to do so? The VNC authentication setup is currently being done per-host, so there is no way to define ACLs per-(user,vm) tuple as you describe. What about the VNC password? That's per-VM, isn't it? That is true by I don't really consider VNC password to be useful. It is utterly insecure. If you want to have plain passwords, then its better to use the new SASL authentication method, with its Digest-MD5 plugin. That is still not top-grade security, but it is better then VNC password and allows configuration of arbitrary Username+pasword pairs.. At which point we just need ACLs against the usernames. SASL also provide Kerberos auth, where we can do an ACL against the Kerberos principle name. And VeNCrypt provides TLS+x509 certificates which you can either layer SASL over again, or require client x509 certs and do an ACL against the client CNAME Ok, so let me sumarize: It is possible to define username+password pairs via SASL. SASL can also sync with Kerberos. So the only problem left is, that there is no way to assign a specific username to a VM. So, what we need is a plugin, where we have an username and a virtual machine as input and we need to refuse the connection, if this pair is not valid. The VNC Server is part of libvirt, so the perfect method to add this functionallity would be the VNC Servers authenticate or start method. However, a Windows user is still not able to connect as there is no windows vnc client capable of doing SASL. GTK-VNC builds on Windows, and so does libvirt. So the intent was that we'd be able to have virt-viewer working on Windows using those two. Oh, when I say Windows, i mean Mingw32 Ok, so the other part of the post is correct? So what do you think about the effort for implementing this feature? Well I've had the demo program from GTK-VNC working sucessfully under Wine, and had virsh successfully working under Wine. So I see no reason why we virt-viewer should be troublesome to get working. I hope it'll just be a lot of silly small bugfixes/portability fixes, rather than any large fundamental problem. Sorry I didn`t express myself clearly. I meant the VNC per-VM auth, but that is useful information, too ;-) -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/3] Re-factor qemu version parsing
On Wed, Jun 10, 2009 at 09:02:39PM +0100, Mark McLoughlin wrote: This patch is purely re-factoring without any functional changes to make way for the next patch. The main thing achieved by the refactoring is that we now have easier access to the parenthesised string that KVM folks seem to delight in changing. Signed-off-by: Mark McLoughlin mar...@redhat.com ACK, this is a nicer separation of work. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/3] Detect newer qemu-kvm versions
On Wed, Jun 10, 2009 at 09:02:40PM +0100, Mark McLoughlin wrote: The KVM version string can be one of the following: - qemu-kvm-x.y.z in stable releases - kvm-XX for kvm versions up to kvm-85 - qemu-kvm-devel-XX for kvm version kvm-86 and later There are only a few of places where we need to detect differences between KVM versions based on 0.9.1: 1) VNET_HDR introduced in kvm-74 2) -incoming tcp introduced in kvm-79 3) -incoming exec introduced in kvm-80 4) -incoming stdio in all earlier kvm versions With qemu-kvm-0.10.x, we can now assume that (1) is available if it's a KVM release, (2) and (3) is always available and (4) is never available. So, from now on we should only need to check the qemu version number and the is_kvm flag for detecting feature availability. We only need the KVM version number for older releases. Signed-off-by: Mark McLoughlin mar...@redhat.com ACK, though the 'is_kvm' flag is a little redundant, since it is implied by kvm_version being != 0. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [CentOS-devel] Latest kvm packages for CentOS 5.3
On Wed, Jun 10, 2009 at 04:50:25PM +0200, Dag Wieers wrote: On Wed, 10 Jun 2009, Federico Simoncelli wrote: I've been working quite extensively with kvm on CentOS 5.3 lately. If you are interested in the latest rpm of kvm-kmod-2.6.30-rc8, qemu-kvm-0.10.5 and libvirt-0.6.4 you can temporary find them here: http://update.nethesis.it/kvm/ I've had no problem so far using these packages. Feedback is welcome. RHEL5.4 is expected to have KVM support, so it would be nice to know in advance which version is being included with RHEL 5.4. Then we can update our own CentOS kvm kmod for testing and reporting upstream the issue(s) we still find. That version info will become available when RHEL-5.4 beta ships in the not too distant future... Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] [v2] Support kvm-img or qemu-img dynamically
On Wed, Jun 10, 2009 at 10:28:00AM -0500, Doug Goldstein wrote: This patch adds a new function virFindFileInPath() and uses it to find where a binary lives in the PATH environment variable. Using this, we can dynamically find where utility functions exist (and if they even exists). So such we remove the build-time check for qemu-img and make it dynamic for kvm-img and qemu-img. Several distros uses kvm-img over qemu-img when installing KVM. kvm-img also includes several patches which Red Hat is trying to upstream with QEMU so this patch supports those features which are commented out in libvirt when using kvm-img That version looks perfect, applied and commited :-) Thanks a lot ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/3] Detect newer qemu-kvm versions
On Thu, 2009-06-11 at 14:12 +0100, Daniel P. Berrange wrote: ACK, though the 'is_kvm' flag is a little redundant, since it is implied by kvm_version being != 0. Nope, kvm_version won't be available after kvm-85 unless we start parsing qemu-kvm-devel-86. The reason I didn't do that is that from now on the qemu version and the is_kvm flag is all we should care about. i.e. since the kvm-XX releases are purely development snapshots, if kvm-87 (based on qemu-0.10.50) introduced something new, we'd only support it for qemu = 0.11.0 and is_kvm == 1. Cheers, Mark. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 3/3] Add qemu help string parsing tests
On Thu, 2009-06-11 at 14:14 +0100, Daniel P. Berrange wrote: .. The test program is only built if WITH_QEMU is defined, so ... ... this source file conditional is redundant. ... And can kill this dummy main() too I didn't dream this up myself, you know ... take a look at qemuxml2argvtest :-) Cheers, Mark. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 3/3] Add qemu help string parsing tests
On Thu, Jun 11, 2009 at 02:23:27PM +0100, Mark McLoughlin wrote: On Thu, 2009-06-11 at 14:14 +0100, Daniel P. Berrange wrote: .. The test program is only built if WITH_QEMU is defined, so ... ... this source file conditional is redundant. ... And can kill this dummy main() too I didn't dream this up myself, you know ... take a look at qemuxml2argvtest :-) Also redundant in that existing test file :-) Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/3] Re-factor qemu version parsing
On Wed, Jun 10, 2009 at 09:02:39PM +0100, Mark McLoughlin wrote:
This patch is purely re-factoring without any functional changes
to make way for the next patch.
The main thing achieved by the refactoring is that we now have
easier access to the parenthesised string that KVM folks seem
to delight in changing.
This kind of parsing looks more flexible to me, even if a bit
less readable than using pure sscanf
[...]
+#define QEMU_VERSION_STRQEMU PC emulator version
+#define KVM_VER_PREFIX (kvm-
+
+static int qemudParseHelpStr(const char *help,
+ unsigned int *flags,
+ unsigned int *version,
+ unsigned int *kvm_version)
+{
+unsigned major, minor, micro;
+const char *p = help;
+
+*flags = *version = *kvm_version = 0;
+
+if (!STRPREFIX(p, QEMU_VERSION_STR))
+goto fail;
+
+p += strlen(QEMU_VERSION_STR);
But I would not integate the spaces in the strings and instead
use a macro like
#define QEMU_VERSION_STRQEMU PC emulator version
#define SKIP_BLANKS(p) while ((*(p) == ' ') || (*(p) == '\t')) (p)++;
and here do SKIP_BLANKS(p)
+major = virParseNumber(p);
+if (major == -1 || *p != '.')
+goto fail;
+
+++p;
+
+minor = virParseNumber(p);
+if (major == -1 || *p != '.')
+goto fail;
+
+++p;
+
+micro = virParseNumber(p);
+if (major == -1)
+goto fail;
and SKIP_BLANKS(p) here
and
#define KVM_VER_PREFIX (kvm-
without the leading space.
+if (STRPREFIX(p, KVM_VER_PREFIX)) {
+int ret;
+
+p += strlen(KVM_VER_PREFIX);
+
+ret = virParseNumber(p);
+if (ret == -1)
+goto fail;
+
+*kvm_version = ret;
[...]
But I'm biased on parsing ... and that's not critical, ACK,
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/3] Detect newer qemu-kvm versions
On Wed, Jun 10, 2009 at 09:02:40PM +0100, Mark McLoughlin wrote: The KVM version string can be one of the following: - qemu-kvm-x.y.z in stable releases - kvm-XX for kvm versions up to kvm-85 - qemu-kvm-devel-XX for kvm version kvm-86 and later Any chance to secure an API in the future from those guys ? But anyway we need to deal with the mess so ... There are only a few of places where we need to detect differences between KVM versions based on 0.9.1: 1) VNET_HDR introduced in kvm-74 2) -incoming tcp introduced in kvm-79 3) -incoming exec introduced in kvm-80 4) -incoming stdio in all earlier kvm versions With qemu-kvm-0.10.x, we can now assume that (1) is available if it's a KVM release, (2) and (3) is always available and (4) is never available. So, from now on we should only need to check the qemu version number and the is_kvm flag for detecting feature availability. We only need the KVM version number for older releases. Signed-off-by: Mark McLoughlin mar...@redhat.com ACK, I don't see a good way to avoid this, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 3/3] Add qemu help string parsing tests
On Wed, Jun 10, 2009 at 09:02:41PM +0100, Mark McLoughlin wrote: Signed-off-by: Mark McLoughlin mar...@redhat.com --- src/qemu_conf.c| 10 +- src/qemu_conf.h|6 ++ tests/Makefile.am |9 ++- tests/qemuhelpdata/kvm-74 | 111 +++ tests/qemuhelpdata/kvm-86 | 170 tests/qemuhelpdata/qemu-0.10.5 | 141 + tests/qemuhelpdata/qemu-0.9.1 | 102 + tests/qemuhelpdata/qemu-kvm-0.10.5 | 155 tests/qemuhelptest.c | 107 ++ 9 files changed, 803 insertions(+), 8 deletions(-) create mode 100644 tests/qemuhelpdata/kvm-74 create mode 100644 tests/qemuhelpdata/kvm-86 create mode 100644 tests/qemuhelpdata/qemu-0.10.5 create mode 100644 tests/qemuhelpdata/qemu-0.9.1 create mode 100644 tests/qemuhelpdata/qemu-kvm-0.10.5 create mode 100644 tests/qemuhelptest.c very good :-) ACK Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/3] Detect newer qemu-kvm versions
On Thu, Jun 11, 2009 at 03:53:15PM +0200, Daniel Veillard wrote: On Wed, Jun 10, 2009 at 09:02:40PM +0100, Mark McLoughlin wrote: The KVM version string can be one of the following: - qemu-kvm-x.y.z in stable releases - kvm-XX for kvm versions up to kvm-85 - qemu-kvm-devel-XX for kvm version kvm-86 and later Any chance to secure an API in the future from those guys ? But anyway we need to deal with the mess so ... In 95% of cases we can ignore the version numbers. We aim to detect new command line features from the help output. And for monitor commands we just try them and catch failure. We just needed this version number for a couple of hacks not covered by those two approaches Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/3] Re-factor qemu version parsing
On Thu, 2009-06-11 at 15:49 +0200, Daniel Veillard wrote:
+#define QEMU_VERSION_STRQEMU PC emulator version
+#define KVM_VER_PREFIX (kvm-
+
+static int qemudParseHelpStr(const char *help,
+ unsigned int *flags,
+ unsigned int *version,
+ unsigned int *kvm_version)
+{
+unsigned major, minor, micro;
+const char *p = help;
+
+*flags = *version = *kvm_version = 0;
+
+if (!STRPREFIX(p, QEMU_VERSION_STR))
+goto fail;
+
+p += strlen(QEMU_VERSION_STR);
But I would not integate the spaces in the strings and instead
use a macro like
#define QEMU_VERSION_STRQEMU PC emulator version
#define SKIP_BLANKS(p) while ((*(p) == ' ') || (*(p) == '\t')) (p)++;
and here do SKIP_BLANKS(p)
Sounds good, committed the below version.
Cheers,
Mark.
From: Mark McLoughlin mar...@redhat.com
Subject: [PATCH 1/3] Re-factor qemu version parsing
This patch is purely re-factoring without any functional changes
to make way for the next patch.
The main thing achieved by the refactoring is that we now have
easier access to the parenthesised string that KVM folks seem
to delight in changing.
Signed-off-by: Mark McLoughlin mar...@redhat.com
---
src/qemu_conf.c | 174 +++
1 files changed, 123 insertions(+), 51 deletions(-)
diff --git a/src/qemu_conf.c b/src/qemu_conf.c
index 2c1eefc..c8f7f0c 100644
--- a/src/qemu_conf.c
+++ b/src/qemu_conf.c
@@ -412,54 +412,12 @@ virCapsPtr qemudCapsInit(void) {
return NULL;
}
-
-int qemudExtractVersionInfo(const char *qemu,
-unsigned int *retversion,
-unsigned int *retflags) {
-const char *const qemuarg[] = { qemu, -help, NULL };
-const char *const qemuenv[] = { LC_ALL=C, NULL };
-pid_t child;
-int newstdout = -1;
-int ret = -1, status;
-unsigned int major, minor, micro;
-unsigned int version, kvm_version;
+static unsigned int qemudComputeCmdFlags(const char *help,
+ unsigned int version,
+ unsigned int kvm_version)
+{
unsigned int flags = 0;
-if (retflags)
-*retflags = 0;
-if (retversion)
-*retversion = 0;
-
-if (virExec(NULL, qemuarg, qemuenv, NULL,
-child, -1, newstdout, NULL, VIR_EXEC_NONE) 0)
-return -1;
-
-char *help = NULL;
-enum { MAX_HELP_OUTPUT_SIZE = 1024*64 };
-int len = virFileReadLimFD(newstdout, MAX_HELP_OUTPUT_SIZE, help);
-if (len 0) {
-virReportSystemError(NULL, errno, %s,
- _(Unable to read QEMU help output));
-goto cleanup2;
-}
-
-if (sscanf(help, QEMU PC emulator version %u.%u.%u (kvm-%u),
- major, minor, micro, kvm_version) != 4)
-kvm_version = 0;
-
-if (!kvm_version
-sscanf(help, QEMU PC emulator version %u.%u.%u,
- major, minor, micro) != 3) {
-char *eol = strchr(help, '\n');
-if (eol) *eol = '\0';
-qemudReportError(NULL, NULL, NULL, VIR_ERR_INTERNAL_ERROR,
- _(cannot parse QEMU version number in '%s'),
- help);
-goto cleanup2;
-}
-
-version = (major * 1000 * 1000) + (minor * 1000) + micro;
-
if (strstr(help, -no-kqemu))
flags |= QEMUD_CMD_FLAG_KQEMU;
if (strstr(help, -no-kvm))
@@ -505,6 +463,125 @@ int qemudExtractVersionInfo(const char *qemu,
flags |= QEMUD_CMD_FLAG_MIGRATE_QEMU_EXEC;
}
+return flags;
+}
+
+/* We parse the output of 'qemu -help' to get the QEMU
+ * version number. The first bit is easy, just parse
+ * 'QEMU PC emulator version x.y.z'.
+ *
+ * With qemu-kvm, however, that is followed by a kvm-XX
+ * string in parenthesis.
+ */
+#define QEMU_VERSION_STRQEMU PC emulator version
+#define KVM_VER_PREFIX (kvm-
+
+#define SKIP_BLANKS(p) do { while ((*(p) == ' ') || (*(p) == '\t')) (p)++; }
while (0)
+
+static int qemudParseHelpStr(const char *help,
+ unsigned int *flags,
+ unsigned int *version,
+ unsigned int *kvm_version)
+{
+unsigned major, minor, micro;
+const char *p = help;
+
+*flags = *version = *kvm_version = 0;
+
+if (!STRPREFIX(p, QEMU_VERSION_STR))
+goto fail;
+
+p += strlen(QEMU_VERSION_STR);
+
+SKIP_BLANKS(p);
+
+major = virParseNumber(p);
+if (major == -1 || *p != '.')
+goto fail;
+
+++p;
+
+minor = virParseNumber(p);
+if (major == -1 || *p != '.')
+goto fail;
+
+++p;
+
+micro = virParseNumber(p);
+if (major == -1)
+goto fail;
+
+SKIP_BLANKS(p);
+
+if (STRPREFIX(p, KVM_VER_PREFIX)) {
+int ret;
+
+p += strlen(KVM_VER_PREFIX);
+
+ret = virParseNumber(p);
+
Re: [libvirt] [PATCH 2/3] Detect newer qemu-kvm versions
On Thu, 2009-06-11 at 15:53 +0200, Daniel Veillard wrote: On Wed, Jun 10, 2009 at 09:02:40PM +0100, Mark McLoughlin wrote: The KVM version string can be one of the following: - qemu-kvm-x.y.z in stable releases - kvm-XX for kvm versions up to kvm-85 - qemu-kvm-devel-XX for kvm version kvm-86 and later Any chance to secure an API in the future from those guys ? Yeah, I posted a patch to implement an info capabilities monitor command a while back, but it didn't end up going anywhere. Committed all the patches now. Cheers, Mark. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/1] Add support for serial number in HAL storage
On Wed, Jun 10, 2009 at 04:20:08PM -0400, Dave Allan wrote: Daniel P. Berrange wrote: On Mon, Jun 08, 2009 at 02:18:14PM -0400, David Allan wrote: --- src/node_device_conf.c |5 + src/node_device_conf.h |1 + src/node_device_hal.c |1 + 3 files changed, 7 insertions(+), 0 deletions(-) ACK, patch looks pretty trivial fine. Could you also extend the docs/schemas/nodedev.rng file and add a file in tests/nodedevschemadata/ with example usage. An additive patch to this one is fine. I think the attached patch does both of those things. Okidoc, applied both patches, the test filename is a bit long but I don't think it's really a problem. thanks ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Improve URI error reporting
On Wed, Jun 03, 2009 at 05:31:13PM +0100, Daniel P. Berrange wrote:
There are currently far too many cases where a correct URI returns an
generic 'failed to connect to hypervisor' error message. This gives the
user no idea why they could not connect. Of particular importance is
that they cannot distinguish a correct URI + plus a driver problem, vs
incorrect URI. Consider the following examples
[...]
The core problem here is that far too many places are using the return
code VIR_DRV_OPEN_DECLINED instead of VIR_DRV_OPEN_ERROR. The former
provides no way to give any error info to the user. With this patch
I have taken the view that a driver must *only* ever use the return
code VIR_DRV_OPEN_DECLINED when:
- Auto-probe of a driver URI, and this driver is not active
- Explicit URI with 'server' specified
- URI scheme does not match the driver
okay
The remote driver is special in that it *must* accept all URIs given to
As long as we check first it's a correct URI...
it, no matter what, unless of course it is running inside the daemon
already. The result is that if you give a correct URI, but there is a
real problem opening the driver you are now guarenteed to get a useful
error message back. Consider the same examples again
yup that looks way better
[...]
-static int openvzProbe(void)
-{
-if (geteuid() == 0
-virFileExists(/proc/vz))
-return 1;
-
-return 0;
-}
-
static virDrvOpenStatus openvzOpen(virConnectPtr conn,
virConnectAuthPtr auth ATTRIBUTE_UNUSED,
int flags ATTRIBUTE_UNUSED)
{
struct openvz_driver *driver;
-if (!openvzProbe())
-return VIR_DRV_OPEN_DECLINED;
if (conn-uri == NULL) {
+if (!virFileExists(/proc/vz))
+return VIR_DRV_OPEN_DECLINED;
+
+if (access(/proc/vz, W_OK) 0)
+return VIR_DRV_OPEN_DECLINED;
+
Okay I was confused at first about dropping geteuid() == 0 check but
it's a more specific check,
conn-uri = xmlParseURI(openvz:///system);
if (conn-uri == NULL) {
-openvzError(conn, VIR_ERR_NO_DOMAIN, NULL);
+virReportOOMError(conn);
Hum ... okay .
[...]
--- a/src/remote_internal.c Wed Jun 03 15:37:52 2009 +0100
+++ b/src/remote_internal.c Wed Jun 03 17:31:17 2009 +0100
@@ -305,21 +305,28 @@ remoteForkDaemon(virConnectPtr conn)
enum virDrvOpenRemoteFlags {
VIR_DRV_OPEN_REMOTE_RO = (1 0),
-VIR_DRV_OPEN_REMOTE_UNIX = (1 1),
-VIR_DRV_OPEN_REMOTE_USER = (1 2),
-VIR_DRV_OPEN_REMOTE_AUTOSTART = (1 3),
-};
-
-/* What transport? */
-enum {
-trans_tls,
-trans_unix,
-trans_ssh,
-trans_ext,
-trans_tcp,
-} transport;
-
-
+VIR_DRV_OPEN_REMOTE_USER = (1 1), /* Use the per-user socket
path */
+VIR_DRV_OPEN_REMOTE_AUTOSTART = (1 2), /* Autostart a per-user daemon
*/
+};
+
+
+/*
+ * URIs that this driver needs to handle:
+ *
+ * The easy answer:
+ * - Everything that no one else has yet claimed, but nothing if
+ * we're inside the libvirtd daemon
+ *
+ * The hard answer:
+ * - Plain paths (///var/lib/xen/xend-socket) - UNIX domain socket
+ * - xxx://servername/ - TLS connection
+ * - xxx+tls://servername/ - TLS connection
+ * - xxx+tls:///- TLS connection to localhost
+ * - xxx+tcp://servername/ - TCP connection
+ * - xxx+tcp:///- TCP connection to localhost
+ * - xxx+unix:/// - UNIX domain socket
+ * - xxx:///- UNIX domain socket
+ */
static int
doRemoteOpen (virConnectPtr conn,
struct private_data *priv,
@@ -328,37 +335,51 @@ doRemoteOpen (virConnectPtr conn,
{
int wakeupFD[2] = { -1, -1 };
char *transport_str = NULL;
+enum {
+trans_tls,
+trans_unix,
+trans_ssh,
+trans_ext,
+trans_tcp,
+} transport;
hum ... I would have expected this to remain global somehow, but
thinking about it, fine :-)
Okay, the changes are larger than I would have expected but it's
similar for all drivers. Looks fine, ACK
thanks !
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] attach-disk (cdrom) requirements
Hello, if the guest is powered off and I run the following command to attach a CD-ROM virsh attach-disk QEmu-fedora-i686-3 myCDROM.iso hdc --driver file --type cdrom --mode readonly I got error: libvir: QEMU error : internal error cannot attach device on inactive domain Is it a requirement to have the guest running to attach a CDROM ? Is there a way to attache a CDROM to a guest powered off with VIRSH I have Compiled against library: libvir 0.6.0 Using library: libvir 0.6.0 Using API: QEMU 0.6.0 Running hypervisor: QEMU 0.10.0 Consider that the above command works if the guest is running. Thanks in advance, Francesco -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] [v2] Support kvm-img or qemu-img dynamically
2009/6/10 Doug Goldstein car...@gentoo.org:
This patch adds a new function virFindFileInPath() and uses it to find
where a binary lives in the PATH environment variable. [...]
+/*
+ * Finds a requested file in the PATH env. e.g.:
+ * kvm-img will return /usr/bin/kvm-img
+ *
+ * You must free the result
+ */
+char *virFindFileInPath(const char *file)
+{
+char pathenv[PATH_MAX];
+char *penv = pathenv; /* this is for glibc 2.10 strsep chnages */
+char *pathseg;
+char fullpath[PATH_MAX];
+
+/* copy PATH env so we can tweak it */
+strncpy(pathenv, getenv(PATH), PATH_MAX);
+pathenv[PATH_MAX - 1] = '\0';
+
+/* for each path segment, append the file to search for and test for
+ * it. return it if found.
+ */
+while ((pathseg = strsep(penv, :)) != NULL) {
+ snprintf(fullpath, PATH_MAX, %s/%s, pathseg, file);
+ if (virFileExists(fullpath))
+ return strdup(fullpath);
+}
+
+return NULL;
+}
GCC (version 4.3.3 here) warns about initialization from incompatible
pointer type at this line:
char *penv = pathenv; /* this is for glibc 2.10 strsep chnages */
Changing it to
char *penv = pathenv; /* this is for glibc 2.10 strsep chnages */
fixes the warning.
At first I was surprised that the first version with works and gives
correct results, then I checked that actual values that are assigned
to char *penv and it's the same in both cases. But the point is: the
additional triggers a warning (breaks compilation with
--enable-compile-warnings=error) and removing it doesn't change the
behavior.
PS: What's this comment about changes in glibc 2.10 to strsep()
referring to? I looked at the changelog but couldn't find any recent
changes to strsep().
Regards,
Matthias
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] getFreeMemory reporting incorrectly?
My apologies. Here it is: Xen 3.3: [r...@node1 ~]# xm info host : node1 release: 2.6.18-128.1.10.el5xen version: #1 SMP Thu May 7 11:51:15 EDT 2009 machine: i686 nr_cpus: 2 nr_nodes : 1 cores_per_socket : 1 threads_per_core : 2 cpu_mhz: 3391 hw_caps: bfebfbff:::0180:441d::: virt_caps : total_memory : 3063 free_memory: 128 node_to_cpu: node0:0-1 node_to_memory : node0:128 xen_major : 3 xen_minor : 3 xen_extra : .1 xen_caps : xen-3.0-x86_32p xen_scheduler : credit xen_pagesize : 4096 platform_params: virt_start=0xf580 xen_changeset : unavailable cc_compiler: gcc version 4.1.2 20071124 (Red Hat 4.1.2-42) cc_compile_by : root cc_compile_domain : gitco.tld cc_compile_date: Tue Jan 20 23:35:28 CET 2009 xend_config_format : 4 Xen 3.0.3: [r...@node2 ~]# xm info host : node2 release: 2.6.18-128.1.6.el5xen version: #1 SMP Wed Apr 1 10:38:05 EDT 2009 machine: i686 nr_cpus: 1 nr_nodes : 1 sockets_per_node : 1 cores_per_socket : 1 threads_per_core : 1 cpu_mhz: 1503 hw_caps: 3febfbff:::0080 total_memory : 2046 free_memory: 256 node_to_cpu: node0:0 xen_major : 3 xen_minor : 1 xen_extra : .2-128.1.6.el5 xen_caps : xen-3.0-x86_32p xen_pagesize : 4096 platform_params: virt_start=0xf580 xen_changeset : unavailable cc_compiler: gcc version 4.1.2 20080704 (Red Hat 4.1.2-44) cc_compile_by : mockbuild cc_compile_domain : centos.org cc_compile_date: Wed Apr 1 09:11:34 EDT 2009 xend_config_format : 2 Hany On Thu, Jun 11, 2009 at 4:46 AM, Daniel P. Berrange berra...@redhat.comwrote: On Wed, Jun 10, 2009 at 07:28:51PM -0400, Hany Fahim wrote: Hey Daniel, Here is the output of 'xm list' from both machines: I wanted the 'xm info' output actually Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/:| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org:| |: http://autobuild.org -o- http://search.cpan.org/~danberr/:| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] getFreeMemory reporting incorrectly?
On Thu, Jun 11, 2009 at 02:13:17PM -0400, Hany Fahim wrote:
My apologies. Here it is:
Xen 3.3:
[r...@node1 ~]# xm info
total_memory : 3063
free_memory: 128
node_to_cpu: node0:0-1
node_to_memory : node0:128
xen_major : 3
xen_minor : 3
xen_extra : .1
Xen 3.0.3:
[r...@node2 ~]# xm info
total_memory : 2046
free_memory: 256
node_to_cpu: node0:0
xen_major : 3
xen_minor : 1
xen_extra : .2-128.1.6.el5
This shows that the Hypervisor is giving correct info back with both
versions. So the problem must be at the libvirt space, and I believe
I know what the problem is.
The version of Xen in RHEL5 has
struct xen_sysctl_availheap {
/* IN variables. */
uint32_t min_bitwidth; /* Smallest address width (zero if don't care). */
uint32_t max_bitwidth; /* Largest address width (zero if don't care). */
int32_t node; /* NUMA node of interest (-1 for all nodes). */
/* OUT variables. */
uint64_t avail_bytes; /* Bytes available in the specified region. */
};
While upstream Xen has
struct xen_sysctl_availheap {
/* IN variables. */
uint32_t min_bitwidth; /* Smallest address width (zero if don't care). */
uint32_t max_bitwidth; /* Largest address width (zero if don't care). */
int32_t node; /* NUMA node of interest (-1 for all nodes). */
/* OUT variables. */
uint64_aligned_t avail_bytes;/* Bytes available in the specified region. */
};
Notice the 'avail_bytes' field is now aligned, so its 4 bytes further
down from where libvirt is expecting it to be.
We'll have to provide a fix in libvirt to use the new alignment for
newer Xen.
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] getFreeMemory reporting incorrectly?
Thanks Daniel,
Is it fair to assume this fix may appear in the next release of libvirt?
Hany
On Thu, Jun 11, 2009 at 2:28 PM, Daniel P. Berrange berra...@redhat.comwrote:
On Thu, Jun 11, 2009 at 02:13:17PM -0400, Hany Fahim wrote:
My apologies. Here it is:
Xen 3.3:
[r...@node1 ~]# xm info
total_memory : 3063
free_memory: 128
node_to_cpu: node0:0-1
node_to_memory : node0:128
xen_major : 3
xen_minor : 3
xen_extra : .1
Xen 3.0.3:
[r...@node2 ~]# xm info
total_memory : 2046
free_memory: 256
node_to_cpu: node0:0
xen_major : 3
xen_minor : 1
xen_extra : .2-128.1.6.el5
This shows that the Hypervisor is giving correct info back with both
versions. So the problem must be at the libvirt space, and I believe
I know what the problem is.
The version of Xen in RHEL5 has
struct xen_sysctl_availheap {
/* IN variables. */
uint32_t min_bitwidth; /* Smallest address width (zero if don't care).
*/
uint32_t max_bitwidth; /* Largest address width (zero if don't care).
*/
int32_t node; /* NUMA node of interest (-1 for all nodes). */
/* OUT variables. */
uint64_t avail_bytes; /* Bytes available in the specified region. */
};
While upstream Xen has
struct xen_sysctl_availheap {
/* IN variables. */
uint32_t min_bitwidth; /* Smallest address width (zero if don't care).
*/
uint32_t max_bitwidth; /* Largest address width (zero if don't care).
*/
int32_t node; /* NUMA node of interest (-1 for all nodes). */
/* OUT variables. */
uint64_aligned_t avail_bytes;/* Bytes available in the specified region.
*/
};
Notice the 'avail_bytes' field is now aligned, so its 4 bytes further
down from where libvirt is expecting it to be.
We'll have to provide a fix in libvirt to use the new alignment for
newer Xen.
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/:|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org:|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/:|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505
:|
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [CentOS-devel] Latest kvm packages for CentOS 5.3
Daniel P. Berrange schrieb: On Wed, Jun 10, 2009 at 04:50:25PM +0200, Dag Wieers wrote: On Wed, 10 Jun 2009, Federico Simoncelli wrote: I've been working quite extensively with kvm on CentOS 5.3 lately. If you are interested in the latest rpm of kvm-kmod-2.6.30-rc8, qemu-kvm-0.10.5 and libvirt-0.6.4 you can temporary find them here: http://update.nethesis.it/kvm/ I've had no problem so far using these packages. Feedback is welcome. RHEL5.4 is expected to have KVM support, so it would be nice to know in advance which version is being included with RHEL 5.4. Then we can update our own CentOS kvm kmod for testing and reporting upstream the issue(s) we still find. That version info will become available when RHEL-5.4 beta ships in the not too distant future... Regards, Daniel I am bitting my nails when that would be... ... any time schedule? Regards, Gerrit -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [CentOS-devel] Latest kvm packages for CentOS 5.3
On Thu, Jun 11, 2009 at 10:17:06PM +0200, Gerrit Slomma wrote: Daniel P. Berrange schrieb: On Wed, Jun 10, 2009 at 04:50:25PM +0200, Dag Wieers wrote: On Wed, 10 Jun 2009, Federico Simoncelli wrote: I've been working quite extensively with kvm on CentOS 5.3 lately. If you are interested in the latest rpm of kvm-kmod-2.6.30-rc8, qemu-kvm-0.10.5 and libvirt-0.6.4 you can temporary find them here: http://update.nethesis.it/kvm/ I've had no problem so far using these packages. Feedback is welcome. RHEL5.4 is expected to have KVM support, so it would be nice to know in advance which version is being included with RHEL 5.4. Then we can update our own CentOS kvm kmod for testing and reporting upstream the issue(s) we still find. That version info will become available when RHEL-5.4 beta ships in the not too distant future... I am bitting my nails when that would be... ... any time schedule? Afraid we don't pre-announce release dates of RHEL. It'll ship when its ready ;-P Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] problems with remote authentication with policykit
Hi, I have libvirt 0.6.4 running kvm instances on a headless server. I'm using virt-manager 0.7.0 to manage them. In the past, I would SSH in and run virt-manager as root. Since running GTK apps as root is no good, I've switched to policykit authentication. By default, the libvirt policy only allows management if the user is in the active host session, which isn't the case with my SSH logins. Therefore I've added an override in /etc/PolicyKit/PolicyKit.conf: match action=org.libvirt.unix.manage return result=auth_admin_keep_session/ /match Now things generally work fine when SSHed in: - as root, virsh gives ro and rw access with no password - as jim, virsh gives ro access with no password, but requests a password for rw - as jim, virsh asks for a password for rw access But when accessing remotely, I get no useful error, and a hang: $ virsh -c qemu+ssh://j...@server/system libvir: Remote error : authentication failed process hangs here $ virsh --readonly -c qemu+ssh://j...@server/system libvir: Remote error : authentication failed process hangs here Furthermore, on the server, this leaves nc processes running, and eventually there are enough that libvirtd stops accepting new connections. I was also getting strange errors including: polkit-grant-helper: given auth type (8 - yes) is bogus but now I can't reproduce that for the life of me, I have no idea what changed. Is policykit authentication supposed to work over qemu+ssh? I was hoping it would at least not break the --readonly case. -jim -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
