[PATCH] Fix the XML we generate for an incoming system to include the <os> block
# HG changeset patch # User Dan Smith <danms@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@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;
+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
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@us.ibm.com
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
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@us.ibm.com
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
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@us.ibm.com
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
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 -=|
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@us.ibm.com
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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
participants (4)
-
Dan Smith -
Daniel P. Berrange -
Daniel Veillard -
Zhengang Li