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 ?