5:39 p.m.
# HG changeset patch
# User Dan Smith <danms(a)us.ibm.com>
# Date 1423944550 28800
# Node ID 5789eadba6e6f71822493043214c3a8749ebb2f6
# Parent babb2ffdc4c2c3f11a3281af4fb33cc3257127f8
Fix the XML we generate for an incoming system to include the <os> block
which seems to be required. Without it, libvirt-0.2.0 seems to break.
Signed-off-by: Dan Smith <danms(a)us.ibm.com>
diff -r babb2ffdc4c2 -r 5789eadba6e6 libxkutil/xmlgen.c
--- a/libxkutil/xmlgen.c Tue Oct 30 11:11:32 2007 -0700
+++ b/libxkutil/xmlgen.c Sat Feb 14 12:09:10 2015 -0800
@@ -33,7 +33,6 @@
#include "cmpimacs.h"
#endif
-#if 0
static char *__tag_attr(struct kv *attrs, int count)
{
char *result = strdup("");
@@ -94,7 +93,6 @@ static char *tagify(char *tagname, char
return result;
}
-#endif
static char *disk_block_xml(const char *path, const char *vdev)
{
@@ -265,11 +263,55 @@ static char *system_xml(struct domain *d
return xml;
}
+static char *os_xml(struct domain *domain)
+{
+ struct os_info *os = &domain->os_info;
+ int ret;
+ char *xml;
+ char *type = NULL;
+ char *kernel = NULL;
+ char *initrd = NULL;
+ char *cmdline = NULL;
+
+ if (os->type == NULL)
+ os->type = strdup("linux");
+
+ if (os->kernel == NULL)
+ os->kernel = strdup("/dev/null");
+
+ type = tagify("type", os->type, NULL, 0);
+ kernel = tagify("kernel", os->kernel, NULL, 0);
+ initrd = tagify("initrd", os->initrd, NULL, 0);
+ cmdline = tagify("cmdline", os->cmdline, NULL, 0);
+
+ ret = asprintf(&xml,
+ "<os>\n"
+ " %s\n"
+ " %s\n"
+ " %s\n"
+ " %s\n"
+ "</os>\n",
+ type,
+ kernel,
+ initrd,
+ cmdline);
+ if (ret == -1)
+ xml = NULL;
+
+ free(type);
+ free(kernel);
+ free(initrd);
+ free(cmdline);
+
+ return xml;
+}
+
char *system_to_xml(struct domain *dominfo)
{
char *devxml = strdup("");
char *sysdevxml = strdup("");
char *sysxml = NULL;
+ char *osxml = NULL;
char *xml = NULL;
int ret;
uint8_t uuid[16];
@@ -285,18 +327,21 @@ char *system_to_xml(struct domain *domin
concat_devxml(&sysdevxml, dominfo->dev_vcpu, dominfo->dev_vcpu_ct);
sysxml = system_xml(dominfo);
+ osxml = os_xml(dominfo);
ret = asprintf(&xml,
"<domain type='xen'>\n"
"<uuid>%s</uuid>\n"
- "%s\n"
- "%s\n"
+ "%s"
+ "%s"
+ "%s"
"<devices>\n"
- "%s\n"
+ "%s"
"</devices>\n"
"</domain>\n",
uuidstr,
sysxml,
+ osxml,
sysdevxml,
devxml);
if (ret == -1)
@@ -304,6 +349,7 @@ char *system_to_xml(struct domain *domin
free(devxml);
free(sysdevxml);
+ free(osxml);
free(sysxml);
return xml;
4:34 a.m.
+1 for the patch. With this patch applied, I can see that the domain is
successfully defined.
Now the method provider (VSMS.DefineSystem) blocks with pegasus on the
trigger_indication() call. Details here:
define_system() --> trigger_indication() --> stdi_trigger_indication()
--> CBInvokeMethod()
Pegasus's provider agent (cimprovagt) got a SIGSEGV when calling
CBInvokeMethod().
--
- Zhengang
8:46 a.m.
ZL> +1 for the patch. With this patch applied, I can see that the domain
ZL> is successfully defined.
Excellent!
ZL> Now the method provider (VSMS.DefineSystem) blocks with pegasus on
ZL> the trigger_indication() call. Details here: define_system() -->
ZL> trigger_indication() --> stdi_trigger_indication()
--> CBInvokeMethod()
Hmm, okay, I'll have to have a look at this. Might be something to do
with our use of the mutex in the indication code. Is your pegasus
using threads or processes?
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms(a)us.ibm.com
5:29 a.m.
Dan Smith wrote:
ZL> Now the method provider (VSMS.DefineSystem) blocks with
pegasus on
ZL> the trigger_indication() call. Details here: define_system() -->
ZL> trigger_indication() --> stdi_trigger_indication()
--> CBInvokeMethod()
Hmm, okay, I'll have to have a look at this. Might be something to do
with our use of the mutex in the indication code. Is your pegasus
using threads or processes?
I can see the log spamming "Thread.cpp" and
"ThreadPool.cpp". I assume
it's using threads.
--
- Zhengang
9:27 a.m.
ZL> I can see the log spamming "Thread.cpp" and "ThreadPool.cpp". I
assume
ZL> it's using threads.
A threads machine should look like this:
% cimconfig -cl | grep -i force
forceProviderProcesses=false
If you don't have a value, set it to true:
% cimconfig -p -s forceProviderProcesses=true
and see if you still get the deadlock.
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms(a)us.ibm.com
4:15 a.m.
Dan Smith wrote:
ZL> I can see the log spamming "Thread.cpp" and
"ThreadPool.cpp". I assume
ZL> it's using threads.
A threads machine should look like this:
% cimconfig -cl | grep -i force
forceProviderProcesses=false
If you don't have a value, set it to true:
% cimconfig -p -s forceProviderProcesses=true
and see if you still get the deadlock.
cimconfig -c -l | grep -i force
forceProviderProcesses=true
Shall I try the threads machine?
--
- Zhengang
9:18 a.m.
ZL> cimconfig -c -l | grep -i force
ZL> forceProviderProcesses=true
Hmm, interesting, that's how mine is configured.
ZL> Shall I try the threads machine?
Sure, it might be interesting for a data point. I'll have to dig into
the indication signaling and see if I can reproduce and figure out
why it's doing that.
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms(a)us.ibm.com
2:44 a.m.
Dan Smith wrote:
ZL> cimconfig -c -l | grep -i force
ZL> forceProviderProcesses=true
Hmm, interesting, that's how mine is configured.
ZL> Shall I try the threads machine?
Sure, it might be interesting for a data point. I'll have to dig into
Samething happened. Segmentation fault.
the indication signaling and see if I can reproduce and figure out
why it's doing that.
--
- Zhengang
7:46 p.m.
On Sat, Feb 14, 2015 at 12:10:01PM -0800, Dan Smith wrote:
Please fix the clock on your computer, or tell me how your time machine
works ;-P
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 -=|
8:21 p.m.
DB> Please fix the clock on your computer, or tell me how your time
DB> machine works ;-P
I know, I sent that from patchbomb inside a VM, which I normally don't
do. Needless to say, the clock had drifted just a bit.
Sorry about that :)
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms(a)us.ibm.com
4:52 a.m.
On Thu, Nov 01, 2007 at 06:21:15PM -0700, Dan Smith wrote:
DB> Please fix the clock on your computer, or tell me how your
time
DB> machine works ;-P
I know, I sent that from patchbomb inside a VM, which I normally don't
do. Needless to say, the clock had drifted just a bit.
Sorry about that :)
Virtualization of time is the next step, I'm sure it's gonna make a huge hit !
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/
6255
days inactive
6262
days old
10 comments
4 participants
participants (4)
-
Dan Smith -
Daniel P. Berrange -
Daniel Veillard -
Zhengang Li