1:55 p.m.
Stumbled across a problem trying to list domains with libvirt-0.1.5.
Using virsh I get errors such as
xen81:/tests/jim # virsh list
Id Name State
----------------------------------
0 Domain-0 running
libvir: Xen Daemon error : GET operation failed: No such domain 16
xm shows
xen81:/tests/jim # xm list
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 2048 4 r----- 815825.8
vm1 1 512 2 -b---- 0.3
I found that the buffer provided for XEN_V1_OP_GETDOMAININFOLIST
hypercall differs slightly from the buffer in xen/dom0_ops.h.
Attached is a patch against current cvs that works for me, but I'm not
familiar with this part of the code so not sure if this is the proper fix.
I'm using xen 3.0.2 that shipped with SLES10.
Regards,
Jim
8:13 p.m.
On Wed, Sep 13, 2006 at 12:55:01PM -0600, Jim Fehlig wrote:
I found that the buffer provided for XEN_V1_OP_GETDOMAININFOLIST
hypercall differs slightly from the buffer in xen/dom0_ops.h.
ohh, that's quite possible I made a mistake in rebuilding the code, yes
Attached is a patch against current cvs that works for me, but
I'm not
familiar with this part of the code so not sure if this is the proper fix.
I will try to double check today or tomorrow as I'm on the road,
thanks a lot for the patch.
I'm using xen 3.0.2 that shipped with SLES10.
Thanks !
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/
11:12 a.m.
On Wed, Sep 13, 2006 at 09:13:35PM -0400, Daniel Veillard wrote:
On Wed, Sep 13, 2006 at 12:55:01PM -0600, Jim Fehlig wrote:
> I found that the buffer provided for XEN_V1_OP_GETDOMAININFOLIST
> hypercall differs slightly from the buffer in xen/dom0_ops.h.
ohh, that's quite possible I made a mistake in rebuilding the code, yes
> Attached is a patch against current cvs that works for me, but I'm not
> familiar with this part of the code so not sure if this is the proper fix.
I will try to double check today or tomorrow as I'm on the road,
thanks a lot for the patch.
Okay, I'm finally back, confirmed my error (sorry I should have tried a
32bit box too but had none handy with the old code). So applied and commited,
thanks a lot !
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/
1:20 p.m.
On Tue, Sep 19, 2006 at 12:12:19PM -0400, Daniel Veillard wrote:
On Wed, Sep 13, 2006 at 09:13:35PM -0400, Daniel Veillard wrote:
> On Wed, Sep 13, 2006 at 12:55:01PM -0600, Jim Fehlig wrote:
> > I found that the buffer provided for XEN_V1_OP_GETDOMAININFOLIST
> > hypercall differs slightly from the buffer in xen/dom0_ops.h.
>
> ohh, that's quite possible I made a mistake in rebuilding the code, yes
>
> > Attached is a patch against current cvs that works for me, but I'm not
> > familiar with this part of the code so not sure if this is the proper fix.
>
> I will try to double check today or tomorrow as I'm on the road,
> thanks a lot for the patch.
Okay, I'm finally back, confirmed my error (sorry I should have tried a
32bit box too but had none handy with the old code). So applied and commited,
Urm, but this has now broken things on 32-bit 3.0.3 based Xen HV.
# virsh dominfo Domain-0 | grep CPU
CPU(s): 115
And also
# virsh vcpuinfo Domain-0
libvir: Xen error : failed Xen syscall ioctl 3166208
Looks like we need different versions of this struct depending on which
Xen we're working against.
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 -=|
3:43 p.m.
On Thu, Sep 28, 2006 at 07:20:35PM +0100, Daniel P. Berrange wrote:
On Tue, Sep 19, 2006 at 12:12:19PM -0400, Daniel Veillard wrote:
> On Wed, Sep 13, 2006 at 09:13:35PM -0400, Daniel Veillard wrote:
> > On Wed, Sep 13, 2006 at 12:55:01PM -0600, Jim Fehlig wrote:
> > > I found that the buffer provided for XEN_V1_OP_GETDOMAININFOLIST
> > > hypercall differs slightly from the buffer in xen/dom0_ops.h.
> >
> > ohh, that's quite possible I made a mistake in rebuilding the code, yes
> >
> > > Attached is a patch against current cvs that works for me, but I'm not
> > > familiar with this part of the code so not sure if this is the proper
fix.
> >
> > I will try to double check today or tomorrow as I'm on the road,
> > thanks a lot for the patch.
>
> Okay, I'm finally back, confirmed my error (sorry I should have tried a
> 32bit box too but had none handy with the old code). So applied and commited,
Urm, but this has now broken things on 32-bit 3.0.3 based Xen HV.
# virsh dominfo Domain-0 | grep CPU
CPU(s): 115
And also
# virsh vcpuinfo Domain-0
libvir: Xen error : failed Xen syscall ioctl 3166208
Looks like we need different versions of this struct depending on which
Xen we're working against.
This is really quite a nasty problem, because the struct is passed into from
numerous locations in the xen_internal.h code & I didn't want to cover the
entire source with conditionals.
So what I've done is declared a new xen_v2_domaininfo struct which is
the same as xen_v0_domaininfo, but with Jim's patch reverted again.
Then provide two unions
union xen_getdomaininfo {
struct xen_v0_getdomaininfo v0;
struct xen_v2_getdomaininfo v2;
};
typedef union xen_getdomaininfo xen_getdomaininfo;
union xen_getdomaininfolist {
struct xen_v0_getdomaininfo *v0;
struct xen_v2_getdomaininfo *v2;
};
typedef union xen_getdomaininfolist xen_getdomaininfolist;
The caller must populate & read either v0, or v2 as apropriate - to avoid
ugly if (hypervisor_version < 2) ...v0... else ...v2... I define a bunhc
of macros for accessing fields in these two unions. eg
#define XEN_GETDOMAININFOLIST_DOMAIN(domlist, n) \
(hypervisor_version < 2 ? \
domlist.v0[n].domain : \
domlist.v2[n].domain)
Or
#define XEN_GETDOMAININFOLIST_CLEAR(domlist, size) \
(hypervisor_version < 2 ? \
memset(domlist.v0, 0, sizeof(xen_v0_getdomaininfo) * size) : \
memset(domlist.v2, 0, sizeof(xen_v2_getdomaininfo) * size))
Anyway, I'm attaching a patch which I've tested against 32-bit HV on both
Xen 3.0.2 and 3.0.3, and also a 64-bit HV on 3.0.2 and 3.0.3 and all the
operations now work correctly again...
Regards,
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 -=|
4:22 p.m.
On Thu, Sep 28, 2006 at 09:43:19PM +0100, Daniel P. Berrange wrote:
On Thu, Sep 28, 2006 at 07:20:35PM +0100, Daniel P. Berrange wrote:
> On Tue, Sep 19, 2006 at 12:12:19PM -0400, Daniel Veillard wrote:
> > On Wed, Sep 13, 2006 at 09:13:35PM -0400, Daniel Veillard wrote:
> > > On Wed, Sep 13, 2006 at 12:55:01PM -0600, Jim Fehlig wrote:
> > > > I found that the buffer provided for XEN_V1_OP_GETDOMAININFOLIST
> > > > hypercall differs slightly from the buffer in xen/dom0_ops.h.
> > >
> > > ohh, that's quite possible I made a mistake in rebuilding the code,
yes
> > >
> > > > Attached is a patch against current cvs that works for me, but
I'm not
> > > > familiar with this part of the code so not sure if this is the proper
fix.
> > >
> > > I will try to double check today or tomorrow as I'm on the road,
> > > thanks a lot for the patch.
> >
> > Okay, I'm finally back, confirmed my error (sorry I should have tried a
> > 32bit box too but had none handy with the old code). So applied and commited,
>
> Urm, but this has now broken things on 32-bit 3.0.3 based Xen HV.
>
> # virsh dominfo Domain-0 | grep CPU
> CPU(s): 115
>
> And also
>
> # virsh vcpuinfo Domain-0
> libvir: Xen error : failed Xen syscall ioctl 3166208
>
> Looks like we need different versions of this struct depending on which
> Xen we're working against.
This is really quite a nasty problem, because the struct is passed into from
numerous locations in the xen_internal.h code & I didn't want to cover the
entire source with conditionals.
So what I've done is declared a new xen_v2_domaininfo struct which is
the same as xen_v0_domaininfo, but with Jim's patch reverted again.
Then provide two unions
Okay, I really expected they didn't broke that data structure too,
sigh ... Yeah go ahead that seems the less uglier possible !
I wonder why I didn't catch that, maybe my 3.0.3 test was done on an x86_64,
thanks !
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/
5:37 p.m.
On Thu, Sep 28, 2006 at 05:22:08PM -0400, Daniel Veillard wrote:
On Thu, Sep 28, 2006 at 09:43:19PM +0100, Daniel P. Berrange wrote:
> On Thu, Sep 28, 2006 at 07:20:35PM +0100, Daniel P. Berrange wrote:
> >
> > Urm, but this has now broken things on 32-bit 3.0.3 based Xen HV.
> >
> > # virsh dominfo Domain-0 | grep CPU
> > CPU(s): 115
> >
> > And also
> >
> > # virsh vcpuinfo Domain-0
> > libvir: Xen error : failed Xen syscall ioctl 3166208
> >
> > Looks like we need different versions of this struct depending on which
> > Xen we're working against.
>
> This is really quite a nasty problem, because the struct is passed into from
> numerous locations in the xen_internal.h code & I didn't want to cover the
> entire source with conditionals.
>
> So what I've done is declared a new xen_v2_domaininfo struct which is
> the same as xen_v0_domaininfo, but with Jim's patch reverted again.
> Then provide two unions
Okay, I really expected they didn't broke that data structure too,
sigh ... Yeah go ahead that seems the less uglier possible !
Ok, I comitted this to CVS now.
I wonder why I didn't catch that, maybe my 3.0.3 test was done on
an x86_64,
Luck. On one of my 32-bit 3.0.3 boxes the 0.1.6 appeared to work fine for the
basic operations - it was just giving bogus data (eg, 153 cpus). Depending on
how many domains were running & what their data was things either silently
worked (but bogus data), or completely crashed & burned.
Anyway, I've now tested this on both versions of HV, and run through valgrind
too as an extra sanity check. Lets just hope Xen doesn't break ABI yet again
in the future....
Regards,
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 -=|
1:31 p.m.
On Thu, Sep 28, 2006 at 11:37:42PM +0100, Daniel P. Berrange wrote:
On Thu, Sep 28, 2006 at 05:22:08PM -0400, Daniel Veillard wrote:
> On Thu, Sep 28, 2006 at 09:43:19PM +0100, Daniel P. Berrange wrote:
> > This is really quite a nasty problem, because the struct is passed into from
> > numerous locations in the xen_internal.h code & I didn't want to cover
the
> > entire source with conditionals.
> >
> > So what I've done is declared a new xen_v2_domaininfo struct which is
> > the same as xen_v0_domaininfo, but with Jim's patch reverted again.
> > Then provide two unions
>
> Okay, I really expected they didn't broke that data structure too,
> sigh ... Yeah go ahead that seems the less uglier possible !
Ok, I comitted this to CVS now.
> I wonder why I didn't catch that, maybe my 3.0.3 test was done on an x86_64,
Luck. On one of my 32-bit 3.0.3 boxes the 0.1.6 appeared to work fine for the
basic operations - it was just giving bogus data (eg, 153 cpus). Depending on
how many domains were running & what their data was things either silently
worked (but bogus data), or completely crashed & burned.
Anyway, I've now tested this on both versions of HV, and run through valgrind
too as an extra sanity check. Lets just hope Xen doesn't break ABI yet again
in the future....
Updating for this ABI breakage is beginning to feel like a never ending
problem :-( It seems I missed one change in my last patch - mlock()'ing
the wrong bit of data for getdomainlist. By (bad) luck it just happened
to work anyway on my tests because I guess there was sufficient allocated
memory that mlock() was still in range. Running unprivileged via the proxy
though, the proxy will always request info on 1020 domains (even if only
a couple are running), which meant we mlock() several 10's of KB of data.
THis ran in an area on unallocated mem & caused mlock() to fail, hence
my discovering the problem.
Anyway, attached is the patch I've applied to CVS...
Regards,
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 -=|
4:26 p.m.
On Mon, Oct 02, 2006 at 07:31:41PM +0100, Daniel P. Berrange wrote:
Updating for this ABI breakage is beginning to feel like a never
ending
problem :-( It seems I missed one change in my last patch - mlock()'ing
the wrong bit of data for getdomainlist. By (bad) luck it just happened
to work anyway on my tests because I guess there was sufficient allocated
memory that mlock() was still in range. Running unprivileged via the proxy
though, the proxy will always request info on 1020 domains (even if only
a couple are running), which meant we mlock() several 10's of KB of data.
THis ran in an area on unallocated mem & caused mlock() to fail, hence
my discovering the problem.
urgh !
Anyway, attached is the patch I've applied to CVS...
Thanks for spotting this! I fixed the munlock -> mlock transition :-)
and updated the error messages to report the new sizes,
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/
6625
days inactive
6644
days old
8 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Jim Fehlig