[libvirt] [PATCH] kvm: maxVCPU runtime detection
Hi, with recent linux kernels we can detect the maximum number of virtual cpus at runtime via an ioctl. Possible patch attached. It does this on every call to qemudGetMaxVCPUs. Would you prefer something that does this only once in qemudStartup()? Cheers, -- Guido
On Fri, Aug 22, 2008 at 03:16:42PM +0200, Guido G?nther wrote:
Hi, with recent linux kernels we can detect the maximum number of virtual cpus at runtime via an ioctl. Possible patch attached. It does this on every call to qemudGetMaxVCPUs. Would you prefer something that does this only once in qemudStartup()? Cheers, -- Guido
+dnl +dnl check for kvm headers +dnl +AC_CHECK_HEADERS([linux/kvm.h])
Hmm, I wonder if that's commonly installed by Fedora/Debian RPMs for KVM.... It might be neccessary to just #define the IOCTL constant in our own header files if its not available.
@@ -72,6 +77,9 @@ static int qemudShutdown(void); #endif
+/* device for kvm ioctls */ +#define KVM_DEVICE "/dev/kvm" + /* qemudDebug statements should be changed to use this macro instead. */ #define DEBUG(fmt,...) VIR_DEBUG(__FILE__, fmt, __VA_ARGS__) #define DEBUG0(msg) VIR_DEBUG(__FILE__, "%s", msg) @@ -1768,6 +1776,29 @@ static const char *qemudGetType(virConnectPtr conn ATTRIBUTE_UNUSED) { return "QEMU"; }
+ +static int kvmGetMaxVCPUs(void) { + int maxvcpus = 1; + +#if defined(KVM_CAP_NR_VCPUS) + int r, fd; + + fd = open(KVM_DEVICE, O_RDONLY); + if (fd < 0) { + qemudLog(QEMUD_WARN, _("Unable to open " KVM_DEVICE ": %s\n"), strerror(errno)); + return maxvcpus; + } + + r = ioctl(fd, KVM_CHECK_EXTENSION, KVM_CAP_NR_VCPUS); + if (r > 0) + maxvcpus = r; + + close(fd); +#endif + return maxvcpus; +}
This is all very cool. IIRC Cole has some code which could guess a reasonable maxvcpus from KVM version number which we could potentially fallback to 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 :|
"Daniel P. Berrange" <berrange@redhat.com> wrote:
On Fri, Aug 22, 2008 at 03:16:42PM +0200, Guido G?nther wrote:
Hi, with recent linux kernels we can detect the maximum number of virtual cpus at runtime via an ioctl. Possible patch attached. It does this on every call to qemudGetMaxVCPUs. Would you prefer something that does this only once in qemudStartup()? Cheers, -- Guido
+dnl +dnl check for kvm headers +dnl +AC_CHECK_HEADERS([linux/kvm.h])
Hmm, I wonder if that's commonly installed by Fedora/Debian RPMs for KVM....
I've just checked up to date rawhide and debian unstable systems. Both had this: $ grep KVM_CHECK_EXTENSION /usr/include/linux/kvm.h #define KVM_CHECK_EXTENSION _IO(KVMIO, 0x03) But rawhide lacks KVM_CAP_NR_VCPUS, while Debian has it. $ grep -r KVM_CAP_NR_VCPUS /usr/include/linux/kvm.h #define KVM_CAP_NR_VCPUS 9 /* returns max vcpus per vm */
It might be neccessary to just #define the IOCTL constant in our own header files if its not available.
Good point. Otherwise, this patch looks fine.
@@ -72,6 +77,9 @@ static int qemudShutdown(void); #endif
+/* device for kvm ioctls */ +#define KVM_DEVICE "/dev/kvm" + /* qemudDebug statements should be changed to use this macro instead. */ #define DEBUG(fmt,...) VIR_DEBUG(__FILE__, fmt, __VA_ARGS__) #define DEBUG0(msg) VIR_DEBUG(__FILE__, "%s", msg) @@ -1768,6 +1776,29 @@ static const char *qemudGetType(virConnectPtr conn ATTRIBUTE_UNUSED) { return "QEMU"; }
+ +static int kvmGetMaxVCPUs(void) { + int maxvcpus = 1; + +#if defined(KVM_CAP_NR_VCPUS) + int r, fd; + + fd = open(KVM_DEVICE, O_RDONLY); + if (fd < 0) { + qemudLog(QEMUD_WARN, _("Unable to open " KVM_DEVICE ": %s\n"), strerror(errno)); + return maxvcpus; + } + + r = ioctl(fd, KVM_CHECK_EXTENSION, KVM_CAP_NR_VCPUS); + if (r > 0) + maxvcpus = r; + + close(fd); +#endif + return maxvcpus; +}
This is all very cool. IIRC Cole has some code which could guess a reasonable maxvcpus from KVM version number which we could potentially fallback to
Daniel
On Fri, Aug 22, 2008 at 07:26:12PM +0200, Jim Meyering wrote: [..snip..]
I've just checked up to date rawhide and debian unstable systems. Both had this:
$ grep KVM_CHECK_EXTENSION /usr/include/linux/kvm.h #define KVM_CHECK_EXTENSION _IO(KVMIO, 0x03)
But rawhide lacks KVM_CAP_NR_VCPUS, while Debian has it.
$ grep -r KVM_CAP_NR_VCPUS /usr/include/linux/kvm.h #define KVM_CAP_NR_VCPUS 9 /* returns max vcpus per vm */
Debian has it only in unstable not in testing. That's why I added the header check as well as the "#if defined(KVM_CAP_NR_VCPUS)" - the code stays as is for old header files and uses the definition (and therefore the ioctl) if available. Rawhide will get the defintion with the next libc header update I guess. -- Guido
Hi, On Fri, Aug 22, 2008 at 02:27:58PM +0100, Daniel P. Berrange wrote:
On Fri, Aug 22, 2008 at 03:16:42PM +0200, Guido G?nther wrote:
Hi, with recent linux kernels we can detect the maximum number of virtual cpus at runtime via an ioctl. Possible patch attached. It does this on every call to qemudGetMaxVCPUs. Would you prefer something that does this only once in qemudStartup()? Cheers, -- Guido
+dnl +dnl check for kvm headers +dnl +AC_CHECK_HEADERS([linux/kvm.h])
Hmm, I wonder if that's commonly installed by Fedora/Debian RPMs for KVM....
It might be neccessary to just #define the IOCTL constant in our own header files if its not available. Attached patch adds the missing definitions via qemu_driver.h which seemed close enough to KVM and isn't a public header. This way all #ifdefs' moved out of qemu_driver.c. -- Guido
Guido Günther wrote:
Hi, On Fri, Aug 22, 2008 at 02:27:58PM +0100, Daniel P. Berrange wrote:
On Fri, Aug 22, 2008 at 03:16:42PM +0200, Guido G?nther wrote:
Hi, with recent linux kernels we can detect the maximum number of virtual cpus at runtime via an ioctl. Possible patch attached. It does this on every call to qemudGetMaxVCPUs. Would you prefer something that does this only once in qemudStartup()? Any comments on this one? Or is this too obviously broken? -- Guido
On Fri, Sep 05, 2008 at 12:16:27PM +0200, Guido G?nther wrote:
Guido Günther wrote:
Hi, On Fri, Aug 22, 2008 at 02:27:58PM +0100, Daniel P. Berrange wrote:
On Fri, Aug 22, 2008 at 03:16:42PM +0200, Guido G?nther wrote:
Hi, with recent linux kernels we can detect the maximum number of virtual cpus at runtime via an ioctl. Possible patch attached. It does this on every call to qemudGetMaxVCPUs. Would you prefer something that does this only once in qemudStartup()? Any comments on this one? Or is this too obviously broken?
I think this is fine to add. We can improve it later if required. 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 :|
Guido Günther wrote:
Guido Günther wrote:
Hi, On Fri, Aug 22, 2008 at 02:27:58PM +0100, Daniel P. Berrange wrote:
On Fri, Aug 22, 2008 at 03:16:42PM +0200, Guido G?nther wrote:
Hi, with recent linux kernels we can detect the maximum number of virtual cpus at runtime via an ioctl. Possible patch attached. It does this on every call to qemudGetMaxVCPUs. Would you prefer something that does this only once in qemudStartup()? Any comments on this one? Or is this too obviously broken? -- Guido
I'm not too savvy on the header stuff but it looks good to me. FYI, I'm about to post a patch that builds on this to offer max vcpu checking based on the kvm version which is parsed from the help message. Should also help providing useful values for older kernels and kvm versions. Thanks, Cole
On Fri, Sep 05, 2008 at 12:23:36PM -0400, Cole Robinson wrote: [..snip..]
FYI, I'm about to post a patch that builds on this to offer max vcpu checking based on the kvm version which is parsed from the help message. Should also help providing useful values for older kernels and kvm versions. This is difficult since different architectures gained vcpu support in different stages but even limited to i386/amd64 this is useful. We should try the ioctal first in any case I think. -- Guido
Hi All, Just wondering has anyone successfully ported libvirt to Mac yet? If yes, could you give some instructions. If not, is there any plans? Thanks. -Yushu
On Fri, Sep 05, 2008 at 10:19:47AM -0700, Yushu Yao wrote:
Hi All,
Just wondering has anyone successfully ported libvirt to Mac yet?
If yes, could you give some instructions. If not, is there any plans?
Well there is porting, which means just being able to compile it without any hypervisor support allowing to do remote access (like for the current Windows port) and that should not be too hard on MacOS-X due to its UNIX lineage. Now support for local virtualization (QEmu for example) would be a more complex issue but probably not much more complex than existing linux hypervisor support. In any case, portability patches are welcome ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
Thanks Daniel,
Now support for local virtualization (QEmu for example) would be a more complex issue but probably not much more complex than existing linux hypervisor support. Why is this more complex? Could you please explain a bit more?
By the way, with libvirt, can I control a hypervisor without the libvirtd running with root privilege (or even without libvirtd running at all?)? Thanks. -Yushu On 9/5/08 11:27 AM, "Daniel Veillard" <veillard@redhat.com> wrote:
On Fri, Sep 05, 2008 at 10:19:47AM -0700, Yushu Yao wrote:
Hi All,
Just wondering has anyone successfully ported libvirt to Mac yet?
If yes, could you give some instructions. If not, is there any plans?
Well there is porting, which means just being able to compile it without any hypervisor support allowing to do remote access (like for the current Windows port) and that should not be too hard on MacOS-X due to its UNIX lineage. Now support for local virtualization (QEmu for example) would be a more complex issue but probably not much more complex than existing linux hypervisor support.
In any case, portability patches are welcome !
Daniel
On Fri, Sep 05, 2008 at 11:43:41AM -0700, Yushu Yao wrote:
Thanks Daniel,
Now support for local virtualization (QEmu for example) would be a more complex issue but probably not much more complex than existing linux hypervisor support. Why is this more complex? Could you please explain a bit more?
Because that's code which would have to be designed/ported, instead of just recompiling completely generic code which has already been ported to Windows.
By the way, with libvirt, can I control a hypervisor without the libvirtd running with root privilege (or even without libvirtd running at all?)?
You should not assume this is possible. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
Hi All, A question when porting to Mac. It says: ld: unknown option: --version-script=./libvirt_sym.version collect2: ld returned 1 exit status make[2]: *** [libvirt.la] Error 1 Indeed --version-script doesn't exist in mac's ld. Can I change it to something else with them same functionality? How should I do it? Thanks. -Yushu
On Mon, Sep 08, 2008 at 08:29:30AM -0700, Yushu Yao wrote:
Hi All,
A question when porting to Mac.
It says:
ld: unknown option: --version-script=./libvirt_sym.version collect2: ld returned 1 exit status make[2]: *** [libvirt.la] Error 1
Indeed --version-script doesn't exist in mac's ld. Can I change it to something else with them same functionality? How should I do it?
I don't know how to do this, I never touched a Mac (well I did once but it sponteaneously rebooted, I assume I'm not compatible). The goal of --version-script=./libvirt_sym.version is to restrict the set of exported symbols available in the library to just the list in libvirt_sym.version and not include all public symbols from the C modules which is the default behaviour. Just find a way to limit the set of public symbols, that has to be possible in some ways. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Mon, Sep 08, 2008 at 08:29:30AM -0700, Yushu Yao wrote:
A question when porting to Mac. It says:
ld: unknown option: --version-script=./libvirt_sym.version collect2: ld returned 1 exit status make[2]: *** [libvirt.la] Error 1
Indeed --version-script doesn't exist in mac's ld. Can I change it to something else with them same functionality? How should I do it?
In practical terms you can just remove that option. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.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 9/8/08 12:17 AM, "Daniel Veillard" <veillard@redhat.com> wrote:
On Fri, Sep 05, 2008 at 11:43:41AM -0700, Yushu Yao wrote:
Thanks Daniel,
Now support for local virtualization (QEmu for example) would be a more complex issue but probably not much more complex than existing linux hypervisor support. Why is this more complex? Could you please explain a bit more?
Because that's code which would have to be designed/ported, instead of just recompiling completely generic code which has already been ported to Windows.
By the way, with libvirt, can I control a hypervisor without the libvirtd running with root privilege (or even without libvirtd running at all?)?
You should not assume this is possible.
Just curious, why there is an option "--without-libvirtd" in configure? (Which actually works and make will not produce libvirtd.exe) Many many thanks for your help! -Yushu
Daniel
On Mon, Sep 08, 2008 at 09:42:32AM -0700, Yushu Yao wrote:
On 9/8/08 12:17 AM, "Daniel Veillard" <veillard@redhat.com> wrote:
On Fri, Sep 05, 2008 at 11:43:41AM -0700, Yushu Yao wrote:
Thanks Daniel,
Now support for local virtualization (QEmu for example) would be a more complex issue but probably not much more complex than existing linux hypervisor support. Why is this more complex? Could you please explain a bit more?
Because that's code which would have to be designed/ported, instead of just recompiling completely generic code which has already been ported to Windows.
By the way, with libvirt, can I control a hypervisor without the libvirtd running with root privilege (or even without libvirtd running at all?)?
You should not assume this is possible.
Just curious, why there is an option "--without-libvirtd" in configure? (Which actually works and make will not produce libvirtd.exe)
The primary use is for people building on Windows, who want to get the libvirt client APIs, but not the server daemon. It lets them managed Linux hosts from Windows. 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 :|
On Fri, Sep 05, 2008 at 10:19:47AM -0700, Yushu Yao wrote:
Just wondering has anyone successfully ported libvirt to Mac yet? If yes, could you give some instructions. If not, is there any plans?
Yes, I've compiled libvirt on Macs in the past. The RPC library supplied with OS X doesn't support 64 bit types, so you have to use PortableXDR as a replacement. Apart from that it should just work, and if it doesn't please report any errors & post patches. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
On Fri, Aug 29, 2008 at 11:33:35PM +0200, Guido Günther wrote:
Attached patch adds the missing definitions via qemu_driver.h which seemed close enough to KVM and isn't a public header. This way all #ifdefs' moved out of qemu_driver.c.
It certainly looks OK from here. However I'm not a real expert on kvm header files and the right way to detect missing features. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.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 Fri, Aug 22, 2008 at 03:16:42PM +0200, Guido Günther wrote:
Hi, with recent linux kernels we can detect the maximum number of virtual cpus at runtime via an ioctl. Possible patch attached. It does this on every call to qemudGetMaxVCPUs. Would you prefer something that does this only once in qemudStartup()? This patch is still outstanding. Anything I can help to push this? -- Guido
On Wed, Sep 17, 2008 at 01:38:49PM +0200, Guido Günther wrote:
On Fri, Aug 22, 2008 at 03:16:42PM +0200, Guido Günther wrote:
Hi, with recent linux kernels we can detect the maximum number of virtual cpus at runtime via an ioctl. Possible patch attached. It does this on every call to qemudGetMaxVCPUs. Would you prefer something that does this only once in qemudStartup()? This patch is still outstanding. Anything I can help to push this?
Can you point me to the latest version? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.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, Sep 17, 2008 at 02:11:46PM +0100, Richard W.M. Jones wrote:
On Wed, Sep 17, 2008 at 01:38:49PM +0200, Guido Günther wrote:
On Fri, Aug 22, 2008 at 03:16:42PM +0200, Guido Günther wrote:
Hi, with recent linux kernels we can detect the maximum number of virtual cpus at runtime via an ioctl. Possible patch attached. It does this on every call to qemudGetMaxVCPUs. Would you prefer something that does this only once in qemudStartup()? This patch is still outstanding. Anything I can help to push this?
Can you point me to the latest version? Attached. -- Guido
On Wed, Sep 17, 2008 at 03:50:06PM +0200, Guido Günther wrote:
On Wed, Sep 17, 2008 at 02:11:46PM +0100, Richard W.M. Jones wrote:
On Wed, Sep 17, 2008 at 01:38:49PM +0200, Guido Günther wrote:
On Fri, Aug 22, 2008 at 03:16:42PM +0200, Guido Günther wrote:
Hi, with recent linux kernels we can detect the maximum number of virtual cpus at runtime via an ioctl. Possible patch attached. It does this on every call to qemudGetMaxVCPUs. Would you prefer something that does this only once in qemudStartup()? This patch is still outstanding. Anything I can help to push this?
Can you point me to the latest version? Attached.
This looks good - I'll commit it in a minute. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
Richard W.M. Jones wrote:
On Wed, Sep 17, 2008 at 01:38:49PM +0200, Guido Günther wrote:
On Fri, Aug 22, 2008 at 03:16:42PM +0200, Guido Günther wrote:
Hi, with recent linux kernels we can detect the maximum number of virtual cpus at runtime via an ioctl. Possible patch attached. It does this on every call to qemudGetMaxVCPUs. Would you prefer something that does this only once in qemudStartup()? This patch is still outstanding. Anything I can help to push this?
Can you point me to the latest version?
Rich.
https://www.redhat.com/archives/libvir-list/2008-August/msg00783.html FYI, I was testing this yesterday. Seems to work fine on f8 and f9. - Cole
participants (7)
-
Cole Robinson -
Daniel P. Berrange -
Daniel Veillard -
Guido Günther -
Jim Meyering -
Richard W.M. Jones -
Yushu Yao