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
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 -=|
participants (2)
-
Daniel P. Berrange -
Richard W.M. Jones