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 ?
Yes, if we are connecting to a xen instance with VMs created outside
libvirt. I think it's okay for us to just key off ',server': mostly
gives the user what they want, and less confusing then requiring
',nowait' to activate ',server'.
I'll update and resend.
- Cole