Hi,
When I attempted to create a stubdom with tls enabled I find
this output in the qemu log:
Error: tls should be a pair, separated by an equals sign.
Using config file "/etc/xen/stubdoms/windowsxp-dm".
windowsxp-dm contains:
#This file is autogenerated, edit windowsxp instead!
kernel = ''/usr/lib/xen/boot/ioemu-stubdom.gz''
vfb = [''sdl=0, opengl=1, xauthority=/root/.Xauthority, vnc=1,
vncdisplay=1,tls, vnclisten=127.0.0.1, vncunused=0'']
disk = [
''phy:sda1,hda:disk,w'',''file:/mnt/launch/XRMPFPP_EN.iso,hdc:cdrom,r''
]
vif = [ ''mac=00:16:3e:04:b2:d5'' ]
At first newbish glance I see that stubdom-dm and image.py use this
information. But, I''m not exactly sure how it''s handled
throughout the
app...
----------------------------------------------------------------------------
---------
xm info:
host : node03
release : 2.6.31-xen-r7
version : #3 SMP Fri Nov 6 16:58:50 PST 2009
machine : x86_64
nr_cpus : 2
nr_nodes : 1
cores_per_socket : 2
threads_per_core : 1
cpu_mhz : 2992
hw_caps :
bfebfbff:20100800:00000000:00000140:0408e3fd:00000000:00000001:00000000
virt_caps : hvm
total_memory : 4093
free_memory : 995
node_to_cpu : node0:0-1
node_to_memory : node0:995
xen_major : 3
xen_minor : 4
xen_extra : .1
xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler : credit
xen_pagesize : 4096
platform_params : virt_start=0xffff800000000000
xen_changeset : unavailable
cc_compiler : gcc version 3.4.6 (Gentoo Hardened 3.4.6-r2 p1.6,
ssp-3.4.6-1.0
cc_compile_by : root
cc_compile_domain : ---------------
cc_compile_date : Sun Nov 8 16:23:49 PST 2009
xend_config_format : 4
----------------------------------------------------------------------------
--------
Any help would be greatly appreciated.
Let me know if you need any additional information...
Thank You,
Dan
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
On 20/11/09 17:53, Dan Hickox wrote:> > > > Error: tls should be a pair, separated by an equals sign. > > Using config file "/etc/xen/stubdoms/windowsxp-dm". > > windowsxp-dm contains: > > #This file is autogenerated, edit windowsxp instead! > > kernel = ''/usr/lib/xen/boot/ioemu-stubdom.gz'' > > vfb = [''sdl=0, opengl=1, xauthority=/root/.Xauthority, vnc=1, > vncdisplay=1,tls, vnclisten=127.0.0.1, vncunused=0''] > > disk = [ > ''phy:sda1,hda:disk,w'',''file:/mnt/launch/XRMPFPP_EN.iso,hdc:cdrom,r'' ] > > vif = [ ''mac=00:16:3e:04:b2:d5'' ] > > At first newbish glance I see that stubdom-dm and image.py use this > information. But, I''m not exactly sure how it''s handled throughout the > app... > >If anything, it should be "tls=1". However, as of 3.4.0 (and possibly later) you don''t do tls like that. Read the tls comments in /etc/xen/xend-config.sxp -- you mostly want to uncomment the "(vnc-tls 1)" line but you''ll need the certificates it mentions in place first. jch _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
John,
Thanks for the response. I did see that much :) Correct me if I''m
wrong; but, it appears that xm create pulls the configuration and formats it
(among other things) and passes the configuration to qemu-dm or in this case
stubdom-dm. It also seems that qemu-dm expects ''tls'' as an
argument and not
''tls=whatever''. The ''tls'' argument was being
auto generated in
''/etc/xen/stubdom'' (I think by the updated stubdom-dm script)
and not
something I had manually appended to the configuration of the VM; and occurs
when (vnc-tls 1) is uncommented.
I was able to patch image.py and create.py to pass the information to
stubdom-dm. Which leaves me with:
INFO (image:394) spawning device models: /usr/lib64/xen/bin/stubdom-dm
[''/usr/lib64/xen/bin/stubdom-dm'', ''-d'',
''23'', ''-domain-name'',
''windowsxp'',
''-videoram'', ''4'', ''-vnc'',
''127.0.0.1:1,tls,x509=/etc/xen/vnc'',
''-vcpus'',
''1'', ''-boot'', ''d'',
''-acpi'', ''-usbdevice'',
''tablet'', ''-net'',
''nic,vlan=1,macaddr=00:16:3e:0a:12:15,model=rtl8139'',
''-net'',
''tap,vlan=1,ifname=tap23.0,bridge=xenbr0'',
''-M'', ''xenfv'']
But, after all this it still appears that tls is either not enabled or there
is some incompatibility between client/server. You wouldn''t happend to
know
a compatible client? I did double check that vnc tls was enabled during
build...
Well... Seems that there is more work to do...
Any suggestions would be appreciated.
Thanks,
Dan
On Mon, Nov 23, 2009 at 4:08 AM, John Haxby <john.haxby@oracle.com> wrote:
> On 20/11/09 17:53, Dan Hickox wrote:
>
>
>
>
> Error: tls should be a pair, separated by an equals sign.
>
> Using config file "/etc/xen/stubdoms/windowsxp-dm".
>
>
>
> windowsxp-dm contains:
>
>
>
> #This file is autogenerated, edit windowsxp instead!
>
> kernel = ''/usr/lib/xen/boot/ioemu-stubdom.gz''
>
> vfb = [''sdl=0, opengl=1, xauthority=/root/.Xauthority, vnc=1,
> vncdisplay=1,tls, vnclisten=127.0.0.1, vncunused=0'']
>
> disk = [ ''phy:sda1,hda:disk,w'',''
> file:/mnt/launch/XRMPFPP_EN.iso,hdc:cdrom,r'' ]
>
> vif = [ ''mac=00:16:3e:04:b2:d5'' ]
>
>
>
> At first newbish glance I see that stubdom-dm and image.py use this
> information. But, I''m not exactly sure how it''s handled
throughout the
> app...
>
>
> If anything, it should be "tls=1".
>
> However, as of 3.4.0 (and possibly later) you don''t do tls like
that.
> Read the tls comments in /etc/xen/xend-config.sxp -- you mostly want to
> uncomment the "(vnc-tls 1)" line but you''ll need the
certificates it
> mentions in place first.
>
> jch
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
On 24/11/09 18:02, Dan Hickox wrote:> John, > Thanks for the response. I did see that much :) Correct me if I''m > wrong; but, it appears that xm create pulls the configuration and > formats it (among other things) and passes the configuration to > qemu-dm or in this case stubdom-dm. It also seems that qemu-dm expects > ''tls'' as an argument and not ''tls=whatever''. The ''tls'' argument was > being auto generated in ''/etc/xen/stubdom'' (I think by the updated > stubdom-dm script) and not something I had manually appended to the > configuration of the VM; and occurs when (vnc-tls 1) is uncommented. > I was able to patch image.py and create.py to pass the information to > stubdom-dm. Which leaves me with: > INFO (image:394) spawning device models: /usr/lib64/xen/bin/stubdom-dm > [''/usr/lib64/xen/bin/stubdom-dm'', ''-d'', ''23'', ''-domain-name'', > ''windowsxp'', ''-videoram'', ''4'', ''-vnc'', ''127.0.0.1:1 > <http://127.0.0.1:1>,tls,x509=/etc/xen/vnc'', ''-vcpus'', ''1'', ''-boot'', > ''d'', ''-acpi'', ''-usbdevice'', ''tablet'', ''-net'', > ''nic,vlan=1,macaddr=00:16:3e:0a:12:15,model=rtl8139'', ''-net'', > ''tap,vlan=1,ifname=tap23.0,bridge=xenbr0'', ''-M'', ''xenfv'']That looks OK.> But, after all this it still appears that tls is either not enabled or > there is some incompatibility between client/server. You wouldn''t > happend to know a compatible client? I did double check that vnc tls > was enabled during build...Check the qemu log files, also check the qemu-dm documentation that describes the set up in some detail. There are two clients that I know work: VenCrypt (http://sourceforge.net/projects/vencrypt/) and gtk-vnc (http://live.gnome.org/gtk-vnc). The example python script in gtk-vnc works as does vinagre (http://projects.gnome.org/vinagre/) which uses gtk-vnc. You''ll need to be careful with your certificates: if you stick to using the fqdn of the various machines involved _everywhere_ then you''ll avoid most of the pitfalls. You can also use wireshark to check on the progress of the TLS negotiation (to a certain extent) but I know when I was doing this I resorted to stepping through the gtk-vnc code with a debugger to find out where I was going wrong.> Well... Seems that there is more work to do... > Any suggestions would be appreciated. >I should have something publicly visible before too long -- I''ll let you know when it''s published. jch _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users