8:47 p.m.
Katti, Vadiraj (STSD-Openview) wrote:
Hi Richard,
DOMFLAGS_DYING is available in dom0_ops.h
# find /usr/include -name '*.h' | xargs grep DOMFLAGS_DYING
/usr/include/xen/dom0_ops.h:#define DOMFLAGS_DYING (1<<0) /* Domain
is scheduled to die. */
I'm pretty certain this is a bug in libvirt, introduced by this patch:
http://www.redhat.com/archives/libvir-list/2007-April/msg00078.html
I think Dan's probably the best one to tell us what's going on here, but
from my understanding the patch above is wrong and should have instead
added this:
#ifndef DOMFLAGS_HVM
#define DOMFLAGS_HVM (1<<1)
#endif
//...
#ifdef DOMFLAGS_HVM
domain_flags &= ~DOMFLAGS_HVM; /* Mask out HVM flags */
#endif
The versions of xen I'm running are :
# rpm -qa |grep -i xen
xen-3.0.4_13138-0.40
xen-doc-html-3.0.4_13138-0.40
xen-devel-3.0_8259-0.1
xen-libs-3.0.4_13138-0.40
kernel-xen-2.6.16.46-0.12
xen-tools-ioemu-3.0.4_13138-0.40
xen-doc-pdf-3.0.4_13138-0.40
xen-tools-3.0.4_13138-0.40
xenstored and xend both of them are running.
# ps -ef|grep xenstored
root 32458 1 0 09:36 ? 00:00:00 xenstored --pid-file
/var/run/xenstore.pid
Now info1 fails with the following error
# ./info1
failed to find libvirt_proxy
Domains 0: 4 CPUs
This was error I had encountered earlier, which is why I wanted to know
what libvirt_proxy does.
I think if the Xen driver can be correctly built then you won't need the
proxy.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
12:11 a.m.
New subject: [Libvir] C bindings
On Tue, Dec 11, 2007 at 12:47:34PM +0000, Richard W.M. Jones wrote:
Katti, Vadiraj (STSD-Openview) wrote:
>Hi Richard,
>
>DOMFLAGS_DYING is available in dom0_ops.h
>
># find /usr/include -name '*.h' | xargs grep DOMFLAGS_DYING
>/usr/include/xen/dom0_ops.h:#define DOMFLAGS_DYING (1<<0) /* Domain
>is scheduled to die. */
I'm pretty certain this is a bug in libvirt, introduced by this patch:
http://www.redhat.com/archives/libvir-list/2007-April/msg00078.html
I think Dan's probably the best one to tell us what's going on here, but
from my understanding the patch above is wrong and should have instead
added this:
#ifndef DOMFLAGS_HVM
#define DOMFLAGS_HVM (1<<1)
#endif
Well the existing code block is this
#ifndef DOMFLAGS_DYING
#define DOMFLAGS_DYING (1<<0) /* Domain is scheduled to die. */
#define DOMFLAGS_HVM (1<<1) /* Domain is HVM */
#define DOMFLAGS_SHUTDOWN (1<<2) /* The guest OS has shut down. */
#define DOMFLAGS_PAUSED (1<<3) /* Currently paused by control software. */
#define DOMFLAGS_BLOCKED (1<<4) /* Currently blocked pending an event. */
#define DOMFLAGS_RUNNING (1<<5) /* Domain is currently running. */
#define DOMFLAGS_CPUMASK 255 /* CPU to which this domain is bound. */
#define DOMFLAGS_CPUSHIFT 8
#define DOMFLAGS_SHUTDOWNMASK 255 /* DOMFLAGS_SHUTDOWN guest-supplied code. */
#define DOMFLAGS_SHUTDOWNSHIFT 16
#endif
So, all the DOMFLAGS_* constants are defined if we don't already have
them. Current Xen headers don't define any of the DOMFLAGS_* values,
but it seems older headers do define some, but not all, which is why
we end up missing the _HVM flag.
To be honest, we should have simply #define'd them all ourselves with a
different namespace to the public Xen headers. We should't rely on any
stuff in the Xen headers since we know they chance that at will.
#ifdef DOMFLAGS_HVM
domain_flags &= ~DOMFLAGS_HVM; /* Mask out HVM flags */
#endif
This #ifdef is unneccessary, since the code higher up should always
define DOMFLAGS_HVM.
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 -=|
6115
days inactive
6115
days old
1 comments
2 participants
participants (2)
-
Daniel P. Berrange -
Richard W.M. Jones