Xen devel - Jul 2006 - [PATCH] Update new qemu-dm to spawn vncviewer

This patch does 3 things to the new device model, qemu-dm:

1)  Add `vncviewer'' as an option to `qemu-dm'' to spawn a
`vncviewer'' process.

2)  Have the `vncviewer'' config parameter translate to the
`vncviewer'' flag to
`qemu-dm''.

3)  Add a new config parameter, `vncconnect'', that spawns a
`vncviewer''
process that looks for a reverse connection (the way the `vncviewer''
config option currently works)


Signed-off-by: Don Dugger <donald.d.dugger@intel.com>

-- 
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Donald.D.Dugger@intel.com
Ph: (303)440-1368


diff -Naur xen-unstable.hg-dm-/tools/python/xen/xend/image.py
xen-unstable.hg-dm/tools/python/xen/xend/image.py
--- xen-unstable.hg-dm-/tools/python/xen/xend/image.py	2006-06-30
15:41:07.000000000 -0600
+++ xen-unstable.hg-dm/tools/python/xen/xend/image.py	2006-07-12
16:31:59.000000000 -0600
@@ -355,18 +355,19 @@
         log.info("device model pid: %d", self.pid)
 
     def vncParams(self):
-        # see if a vncviewer was specified
+        # see if a vncconnect or vncviewer was specified
         # XXX RN: bit of a hack. should unify this, maybe stick in config space
-        vncconnect=[]
+        parm=[]
         args = self.cmdline
         if args:
             arg_list = string.split(args)
             for arg in arg_list:
                 al = string.split(arg, ''='')
-                if al[0] == "VNC_VIEWER":
-                    vncconnect=["-vncconnect", "%s" %
al[1]]
-                    break
-        return vncconnect
+                if al[0] == "VNC_CONNECT":
+                    parm=parm + ["-vncconnect", "%s" %
al[1]]
+		elif al[0] == "VNC_VIEWER":
+                    parm=parm + ["-vncviewer"]
+        return parm
 
     def destroy(self):
         self.unregister_shutdown_watch();
diff -Naur xen-unstable.hg-dm-/tools/python/xen/xm/create.py
xen-unstable.hg-dm/tools/python/xen/xm/create.py
--- xen-unstable.hg-dm-/tools/python/xen/xm/create.py	2006-06-30
15:41:37.000000000 -0600
+++ xen-unstable.hg-dm/tools/python/xen/xm/create.py	2006-07-12
14:40:59.000000000 -0600
@@ -102,7 +102,7 @@
           fn=set_true, default=0,
           use="Connect to the console after the domain is created.")
 
-gopts.var(''vncviewer'', val=''no|yes'',
+gopts.var(''vncconnect'', val=''no|yes'',
           fn=set_bool, default=None,
           use="""Spawn a vncviewer listening for a vnc server in
the domain.
           The address of the vncviewer is passed to the domain on the kernel
command
@@ -111,6 +111,12 @@
           Only valid when vnc=1.
           """)
 
+gopts.var(''vncviewer'', val=''no|yes'',
+          fn=set_bool, default=None,
+          use="""Spawn a vncviewer process for the domain.
+          Only valid when vnc=1.
+          """)
+
 gopts.var(''name'', val=''NAME'',
           fn=set_value, default=None,
           use="Domain name. Must be unique.")
@@ -618,8 +624,8 @@
     """
     args = [ ''device_model'', ''pae'',
''vcpus'', ''cdrom'', ''boot'',
''fda'', ''fdb'',
              ''localtime'', ''serial'',
''stdvga'', ''isa'',
''nographic'', ''audio'',
-             ''vnc'', ''vncviewer'',
''sdl'', ''display'',
''ne2000'', ''acpi'', ''apic'',
-             ''xauthority'', ''usb'',
''usbdevice'' ]
+             ''vnc'', ''vncconnect'',
''vncviewer'', ''sdl'',
''display'', ''ne2000'',
+	     ''acpi'', ''apic'',
''xauthority'', ''usb'',
''usbdevice'' ]
     for a in args:
         if (vals.__dict__[a]):
             config_image.append([a, vals.__dict__[a]])
@@ -847,17 +853,20 @@
     """If vnc was specified, spawn a vncviewer in listen mode
     and pass its address to the domain on the kernel command line.
     """
-    if not (vals.vnc and vals.vncviewer) or vals.dryrun: return
-    vnc_display = choose_vnc_display()
-    if not vnc_display:
-        warn("No free vnc display")
-        return
-    print ''VNC='', vnc_display
-    vnc_port = spawn_vnc(vnc_display)
-    if vnc_port > 0:
-        vnc_host = get_host_addr()
-        vnc = ''VNC_VIEWER=%s:%d'' % (vnc_host, vnc_port)
-        vals.extra = vnc + '' '' + vals.extra
+    if not vals.vnc or vals.dryrun: return
+    if vals.vncconnect:
+	vnc_display = choose_vnc_display()
+	if not vnc_display:
+	    warn("No free vnc display")
+	    return
+	print ''VNC='', vnc_display
+	vnc_port = spawn_vnc(vnc_display)
+	if vnc_port > 0:
+	    vnc_host = get_host_addr()
+	    vnc = ''VNC_CONNECT=%s:%d'' % (vnc_host, vnc_port)
+	    vals.extra = vnc + '' '' + vals.extra
+    if vals.vncviewer:
+	vals.extra = ''VNC_VIEWER=yes'' + vals.extra
     
 def preprocess(vals):
     if not vals.kernel and not vals.bootloader:
diff -Naur xen-unstable.hg-dm-/tools/xs-tools-ioemu/vl.c
xen-unstable.hg-dm/tools/xs-tools-ioemu/vl.c
--- xen-unstable.hg-dm-/tools/xs-tools-ioemu/vl.c	2006-06-30 15:41:14.000000000
-0600
+++ xen-unstable.hg-dm/tools/xs-tools-ioemu/vl.c	2006-07-12 16:16:42.000000000
-0600
@@ -111,6 +111,8 @@
 /* XXX: use a two level table to limit memory usage */
 #define MAX_IOPORTS 65536
 
+#define VNC_BASE_PORT	5900
+
 const char *bios_dir = CONFIG_QEMU_SHAREDIR;
 char phys_ram_file[1024];
 void *ioport_opaque[MAX_IOPORTS];
@@ -121,6 +123,7 @@
 int bios_size;
 static DisplayState display_state;
 int nographic;
+int vncviewer;
 const char* keyboard_layout = NULL;
 int64_t ticks_per_sec;
 int boot_device = ''c'';
@@ -4801,6 +4804,7 @@
 #endif
            "-loadvm file    start right away with a saved state (loadvm in
monitor)\n"
 	   "-vnc display    start a VNC server on display\n"
+	   "-vncviewer      start a vncviewer process for this domain\n"
            "-timeoffset     time offset (in seconds) from local
time\n"
            "\n"
            "During emulation, the following keys are useful:\n"
@@ -4889,6 +4893,7 @@
     QEMU_OPTION_usbdevice,
     QEMU_OPTION_smp,
     QEMU_OPTION_vnc,
+    QEMU_OPTION_vncviewer,
 
     QEMU_OPTION_d,
     QEMU_OPTION_vcpus,
@@ -4964,6 +4969,7 @@
     { "usbdevice", HAS_ARG, QEMU_OPTION_usbdevice },
     { "smp", HAS_ARG, QEMU_OPTION_smp },
     { "vnc", HAS_ARG, QEMU_OPTION_vnc },
+    { "vncviewer", 0, QEMU_OPTION_vncviewer },
     
     /* temporary options */
     { "usb", 0, QEMU_OPTION_usb },
@@ -5240,6 +5246,31 @@
     return 0;
 }
 
+int start_viewer(int port)
+{
+    int pid;
+    char ports[16];
+
+    sprintf(ports, ":%d", VNC_BASE_PORT + port);
+    switch (pid = fork()) {
+
+    case -1:
+	fprintf(stderr, "vncviewer failed fork\n");
+	exit(1);
+
+    case 0:	/* child */
+	execlp("vncviewer", "vncviewer", "-log",
"*:stdout:0", ports, 0);
+	fprintf(stderr, "vncviewer execlp failed\n");
+	exit(1);
+
+    default:
+	return pid;
+
+    }
+    fprintf(stderr, "Compiler error?\n");
+    return -1;
+}
+
 int main(int argc, char **argv)
 {
 #ifdef CONFIG_GDBSTUB
@@ -5294,6 +5325,7 @@
 #endif
     snapshot = 0;
     nographic = 0;
+    vncviewer = 0;
     kernel_filename = NULL;
     kernel_cmdline = "";
 #ifdef TARGET_PPC
@@ -5663,6 +5695,9 @@
 		    exit(1);
 		}
 		break;
+	    case QEMU_OPTION_vncviewer:
+		vncviewer++;
+		break;
             case QEMU_OPTION_domainname:
                 strncat(domain_name, optarg, sizeof(domain_name) - 20);
                 break;
@@ -5879,6 +5914,8 @@
         dumb_display_init(ds);
     } else if (vnc_display != -1) {
 	vnc_display_init(ds, vnc_display);
+	if (vncviewer)
+	    start_viewer(vnc_display);
     } else {
 #if defined(CONFIG_SDL)
         sdl_display_init(ds, full_screen);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 7/13/06, Donald D. Dugger <donald.d.dugger@intel.com>
wrote:
> This patch does 3 things to the new device model, qemu-dm:
>
> 1)  Add `vncviewer'' as an option to `qemu-dm'' to spawn a
`vncviewer'' process.
>
> 2)  Have the `vncviewer'' config parameter translate to the
`vncviewer'' flag to
> `qemu-dm''.
>
> 3)  Add a new config parameter, `vncconnect'', that spawns a
`vncviewer''
> process that looks for a reverse connection (the way the
`vncviewer''
> config option currently works)
>
>
> Signed-off-by: Don Dugger <donald.d.dugger@intel.com>
Thanks, I''ve checked this in with the following changes:
- support xvncviewer, xvnc4viewer and xtightvncviewer (all support
:DISPLAY, only two support :PORTNO, only one supports -log)
- use vncconsole config option instead of vncviewer option, leaving
the existing vncviewer option as is
- don''t abuse the command line to pass the option to xend but pass it
along all other options
- don''t add vnc specific code to qemu''s vl.c but put it in
vnc.c instead
- don''t handle/pass vncviewer config option for hvm guests any longer
in/to xend -- it should be handled inside the guest

We''ll want to make the vncconsole option also work with the
framebuffer for PV guests.  It then makes sense to have both in that
case -- vncviewer gets you a vncviewer to a vnc server running in the
guest, vncconsole gets you a vncviewer to the vnc server rendering the
guest''s framebuffer.

    christian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, 2006-07-12 at 21:04 -0700, Donald D. Dugger
wrote:
> 1)  Add `vncviewer'' as an option to `qemu-dm'' to spawn a
`vncviewer'' process.
Doesn''t it make sense to push these sorts of changes to Fabrice and not
include them as a Xen patch until they''re included in upstream qemu?
Otherwise, how do we avoid ending up back in the same place where we
have a huge pile of Xen specific patches making it very difficult to
rebase to a new version of qemu?

Jeremy


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 7/20/06, Jeremy Katz <katzj@redhat.com> wrote:
> On Wed, 2006-07-12 at 21:04 -0700, Donald D. Dugger wrote:
> > 1)  Add `vncviewer'' as an option to `qemu-dm'' to
spawn a `vncviewer'' process.
>
> Doesn''t it make sense to push these sorts of changes to Fabrice
and not
> include them as a Xen patch until they''re included in upstream
qemu?
> Otherwise, how do we avoid ending up back in the same place where we
> have a huge pile of Xen specific patches making it very difficult to
> rebase to a new version of qemu?
I don''t think that we will end up in the same place because we keep
each feature as a separate patch.  It would certainly be good to push
changes which are generic enough to Fabrice, but I don''t think we want
to wait with including the changes until they get included in an
upstream qemu version, especially since we will still be quite slow in
upgrading qemu.

Do you want to push suitable changes to Fabrice?  Anybody?

    christian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel