Cole Robinson wrote:
'listen' isn't a valid qemu-dm option, as reported a long time ago here:
https://bugzilla.redhat.com/show_bug.cgi?id=492958
Matches the near identical logic in qemu_conf.c ... diff --git a/src/xen/xend_internal.c b/src/xen/xend_internal.c index a99cc7b..e12bac7 100644 --- a/src/xen/xend_internal.c +++ b/src/xen/xend_internal.c @@ -1276,7 +1276,7 @@ xenDaemonParseSxprChar(const char *value, if (def->data.tcp.service == NULL) goto no_memory;
- if (offset2 && strstr(offset2, ",listen")) + if (offset2 && strstr(offset2, ",server,nowait")) def->data.tcp.listen = 1; } break; @@ -1332,7 +1332,7 @@ xenDaemonParseSxprChar(const char *value, goto no_memory;
if (offset != NULL && - strstr(offset, ",listen") != NULL) + strstr(offset, ",server,nowait") != NULL) def->data.nix.listen = 1; } break; @@ -5209,7 +5209,7 @@ xenDaemonFormatSxprChr(virDomainChrDefPtr def, "tcp" : "telnet"), (def->data.tcp.host ? def->data.tcp.host : ""), (def->data.tcp.service ? def->data.tcp.service : ""), - (def->data.tcp.listen ? ",listen" : "")); + (def->data.tcp.listen ? ",server,nowait" : "")); break;
case VIR_DOMAIN_CHR_TYPE_UDP: @@ -5223,7 +5223,7 @@ xenDaemonFormatSxprChr(virDomainChrDefPtr def, case VIR_DOMAIN_CHR_TYPE_UNIX: virBufferVSprintf(buf, "%s:%s%s", type, def->data.nix.path, - def->data.nix.listen ? ",listen" : ""); + def->data.nix.listen ? ",server,nowait" : "");
ACK on the basis of similarity to existing code in qemu_conf.c as you noted. However, is it possible to encounter the option names ordered the other way: ",nowait,server" -- or even with some unrelated option between them ?