8:16 a.m.
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
8:27 a.m.
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 :|
12:26 p.m.
"Daniel P. Berrange" <berrange(a)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
1:21 p.m.
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
4:33 p.m.
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
5:16 a.m.
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
6:39 a.m.
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 :|
11:23 a.m.
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
2:45 p.m.
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
12:19 p.m.
New subject: [libvirt] Mac Port of Libvirt
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
1:27 p.m.
New subject: [libvirt] Mac Port of Libvirt
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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
1:43 p.m.
New subject: [libvirt] Mac Port of Libvirt
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(a)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
2:17 a.m.
New subject: [libvirt] Mac Port of Libvirt
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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
10:29 a.m.
New subject: [libvirt] ld: unknown option: --version-script
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
11:24 a.m.
New subject: [libvirt] ld: unknown option: --version-script
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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
3:08 a.m.
New subject: [libvirt] ld: unknown option: --version-script
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
11:42 a.m.
New subject: [libvirt] Mac Port of Libvirt
On 9/8/08 12:17 AM, "Daniel Veillard" <veillard(a)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
11:45 a.m.
New subject: [libvirt] Mac Port of Libvirt
On Mon, Sep 08, 2008 at 09:42:32AM -0700, Yushu Yao wrote:
On 9/8/08 12:17 AM, "Daniel Veillard" <veillard(a)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 :|
3:07 a.m.
New subject: [libvirt] Mac Port of Libvirt
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
5:49 a.m.
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
6:38 a.m.
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
8:11 a.m.
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
8:50 a.m.
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
8:52 a.m.
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
8:51 a.m.
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
5909
days inactive
5935
days old
24 comments
7 participants
participants (7)
-
Cole Robinson -
Daniel P. Berrange -
Daniel Veillard -
Guido Günther -
Jim Meyering -
Richard W.M. Jones -
Yushu Yao