[Libvir] PATCH: Don't auto-set VNC port to 5900+domid

The current code for stuffing the VNC port number into the XML looks in XenStore for the VNC port number, and if it does not find it there falls back to using 5900+domid. This is a problem because it leaves open a race condition where the VNC daemon for a guest may not have started up yet, and so if an app requests the XML at this time it'll get potentially bogus port number info. In the best case there will be nothing listening on the bogus port, in the worst case a completely different domain will be listening on that port. This scenario is described here http://www.redhat.com/archives/et-mgmt-tools/2007-February/msg00115.html The reason we have the 5900+domid rule in there is to support Xen 3.0.2 or earlier, where the port number was never stored in XenStore. For any Xen 3.0.3 or later, we should basically never use the 5900+domid fallback rule. So the attached patch makes it conditional on xendConfigVersion < 2 Regards, 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 -=|

Hi, Dan On Thu, 22 Feb 2007 22:10:02 +0000 "Daniel P. Berrange" wrote:
The current code for stuffing the VNC port number into the XML looks in XenStore for the VNC port number, and if it does not find it there falls back to using 5900+domid. This is a problem because it leaves open a race condition where the VNC daemon for a guest may not have started up yet, and so if an app requests the XML at this time it'll get potentially bogus port number info. In the best case there will be nothing listening on the bogus port, in the worst case a completely different domain will be listening on that port.
This scenario is described here
http://www.redhat.com/archives/et-mgmt-tools/2007-February/msg00115.html
The reason we have the 5900+domid rule in there is to support Xen 3.0.2 or earlier, where the port number was never stored in XenStore. For any Xen 3.0.3 or later, we should basically never use the 5900+domid fallback rule. So the attached patch makes it conditional on xendConfigVersion < 2
The patch is only for PV, isn't it? I think we need to fix for HVM too, like the one you have. How does that sound? Signed-off-by: Saori Fukuta <fukuta.saori@jp.fujitsu.com> Thanks, Saori Fukuta. Index: src/xend_internal.c =================================================================== --- xend_internal.c 2007-02-27 03:53:05.000000000 +0900 +++ xend_internal.c.new 2007-02-27 03:51:30.000000000 +0900 @@ -1617,7 +1617,7 @@ xend_parse_sexp_desc(virConnectPtr conn, if (tmp[0] == '1') { int port = xenStoreDomainGetVNCPort(conn, domid); const char *listenAddr = sexpr_fmt_node(root, "domain/image/%s/vnclisten", hvm ? "hvm" : "linux"); - if (port == -1) + if (port == -1 && xendConfigVersion < 2) port = 5900 + domid; if (listenAddr) virBufferVSprintf(&buf, " <graphics type='vnc' port='%d' listen='%s'/>\n", port, listenAddr);
participants (2)
-
Daniel P. Berrange
-
Saori Fukuta