11:49 a.m.
I just saw an email about unsigned long and max memory fly by along with
a comment like "32-bit will never have more than 'X' Gb" ...
This raises an obvious question: is libvirt explictly not 32/64 clean?
On Solaris we build everything 32-bit by default unless there is a
reason for it to be 64-bit. If a 32-bit libvirt can't handle a 64-bit
kernel, then we have a problem.
IMO an API should *always* use explicitly-sized integers when they
contain range or size values (or use size_t etc.). Not doing so is both
dangerous and confusing...
(Xen does indeed have this problem, so we run all their tools with
native word size. Currently we always use a 32-bit libvirt for
'virt-install', and it does seem to work fine. It would be a pity for
this to change).
cheers
john
9:08 p.m.
On Tue, Sep 11, 2007 at 05:49:08PM +0100, John Levon wrote:
I just saw an email about unsigned long and max memory fly by along with
a comment like "32-bit will never have more than 'X' Gb" ...
This raises an obvious question: is libvirt explictly not 32/64 clean?
On Solaris we build everything 32-bit by default unless there is a
reason for it to be 64-bit. If a 32-bit libvirt can't handle a 64-bit
kernel, then we have a problem.
Indeed. This scenario of 64-bit HV with 32-bit Dom0 userspace is entirely
possible on Linux too. In PPC world its actually more efficient to use 32-bit
userspace unless a particular app needs 64-bit memory addressing - most of
the Fedora PPC rpms are 32-bit for this reason even on PPC64 platforms.
IMO an API should *always* use explicitly-sized integers when they
contain range or size values (or use size_t etc.). Not doing so is both
dangerous and confusing...
We've got an issue with some existing APIs using 'unsigned long' for memory
values in KB. This may eventually force us to implement parallel APIs for
these functions taking a 'long long'. We should not introduce any new APIs
which are 'unsigned long' unless we know absolutely that 32-bits is enough
even on a 64-bit system.
(Xen does indeed have this problem, so we run all their tools with
native word size. Currently we always use a 32-bit libvirt for
'virt-install', and it does seem to work fine. It would be a pity for
this to change).
We definitely need to support 32-bit tools on 64-bit HV
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
9:40 p.m.
On Wed, Sep 12, 2007 at 03:08:32AM +0100, Daniel P. Berrange wrote:
We definitely need to support 32-bit tools on 64-bit HV
Thanks. Mark Johnson pointed out that we get away with a 32-bit
virt-install right now simply because the hypercall libvirt backend
fails, and falls back to calling into xend. In general this works well,
but seems to have at least one issue that means we might need to create
a 64-bit virt-{install,manager} ...
regards
john
9:50 p.m.
On Wed, Sep 12, 2007 at 03:40:49AM +0100, John Levon wrote:
On Wed, Sep 12, 2007 at 03:08:32AM +0100, Daniel P. Berrange wrote:
> We definitely need to support 32-bit tools on 64-bit HV
Thanks. Mark Johnson pointed out that we get away with a 32-bit
virt-install right now simply because the hypercall libvirt backend
fails, and falls back to calling into xend. In general this works well,
but seems to have at least one issue that means we might need to create
a 64-bit virt-{install,manager} ...
That's odd - to be able to run a 32-bit userspace on 64-bit HV you must
be running a Xen 3.1 release or later. If using that, then libvirt should
have automatically detected the hypervisor ABI which is 32/64 invariant.
ie it ought to be working ! Your problem could be a compatability issue
between the Solaris & Linux Xen ABIs which we're getting wrong.
You really want to be letting libvirt use the HV because for calls such
as listing guests, getting domain stats we get x100 to x1000 lower overheads
from talking to the HV instead of XenD. Talking to XenD you'll quickly see
XenD and XenStoreD start to take up considerable CPU time in Dom0 with even
a few guests being monitored by virt-manager.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
10:04 p.m.
On Wed, Sep 12, 2007 at 03:50:23AM +0100, Daniel P. Berrange wrote:
> Thanks. Mark Johnson pointed out that we get away with a 32-bit
> virt-install right now simply because the hypercall libvirt backend
> fails, and falls back to calling into xend. In general this works well,
> but seems to have at least one issue that means we might need to create
> a 64-bit virt-{install,manager} ...
That's odd - to be able to run a 32-bit userspace on 64-bit HV you must
be running a Xen 3.1 release or later. If using that, then libvirt should
We're using 3.0.4. I believe that virt-install is only using calls that
can be supplied by the xend backend, so the fact that the hypercall
backend doesn't work doesn't matter.
You really want to be letting libvirt use the HV because for calls
such
as listing guests, getting domain stats we get x100 to x1000 lower overheads
from talking to the HV instead of XenD. Talking to XenD you'll quickly see
Right. A 3.1 upgrade is planned soon, and we'll probably just do this to
resolve the issue.
regards,
john
1:20 a.m.
On Tue, Sep 11, 2007 at 05:49:08PM +0100, John Levon wrote:
I just saw an email about unsigned long and max memory fly by along with
a comment like "32-bit will never have more than 'X' Gb" ...
This raises an obvious question: is libvirt explictly not 32/64 clean?
On Solaris we build everything 32-bit by default unless there is a
reason for it to be 64-bit. If a 32-bit libvirt can't handle a 64-bit
kernel, then we have a problem.
Okay, I didn't realize that. Could you check what part of the API
which are currently a problem w.r.t. this ? It would be good to have
a list, and okay we should use long long for the NUMA cell free query
API...
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
10:28 a.m.
On Wed, Sep 12, 2007 at 02:20:21AM -0400, Daniel Veillard wrote:
> I just saw an email about unsigned long and max memory fly by
along with
> a comment like "32-bit will never have more than 'X' Gb" ...
>
> This raises an obvious question: is libvirt explictly not 32/64 clean?
> On Solaris we build everything 32-bit by default unless there is a
> reason for it to be 64-bit. If a 32-bit libvirt can't handle a 64-bit
> kernel, then we have a problem.
Okay, I didn't realize that. Could you check what part of the API
which are currently a problem w.r.t. this ? It would be good to have
a list, and okay we should use long long for the NUMA cell free query
API...
That's a good question. We should indeed do an audit so we can be aware
of problems. Hopefully we'll find time to do a quick sweep as move up to
more recent versions...
regards
john
6312
days inactive
6313
days old
6 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
John Levon