Xen devel - Oct 2011 - Problems with 'xl create winxp' (hvm) on xen 4.1.2 (also affects GPLPV)

Setup:

Fedora 15, w/f16''s 3.1.0 (also tried 2.6.40 & 3.0.0)
xen 4.1.2 (newly upgraded from 4.1.1, from rawhide)

Since the release notes for 4.1.2 said, in part:

Fixes/features include:
 * New XL toolstack

I decided to test some problems I saw using xl to start a winxp hvm domu under 
xen 4.1.1, and found that they were still there, and I came up with a somewhat 
more serious one as well. I''m sure that others can point out more
serious
problems, but these are the ones that affect me. In all cases, ''xm
create''
does not have these problems. Domu config at the end of the post.

New to 4.1.2:

1) Starting winxp with xl does not create a vif interface - only a tap one. 
More exactly, the vif is created, but does not get an ipv6 address - it shows 
up in ''ifconfig -a'', or ''ifconfig vifn.0'' -
and does not get added to the
bridge. If you are using James'' GPLPV drivers, you end up with no
network
connectivity, as they use vif, not tap. I''d be surprised if other pvhvm
solutions don''t see this also.

To be clear, ''xm create winxp'' correctly puts vif on the
bridge, nor did xl
have this problem under xen 4.1.1. Also, this is an hvm problem. ''xl
create''-
ing a pv domu correctly puts the vif on a bridge.

For the remaining problems, note that ''xl create winxp''
creates a qemu-dm
process with the following parameters:

qemu-dm -d 8 -domain-name winxp -vnc 0.0.0.0:3 -k en-us -serial pty -videoram 
4 -boot cda -usb -usbdevice tablet -soundhw es1370 -acpi -vcpus 2 -vcpu_avail 
0x3 -net nic,vlan=0,macaddr=00:16:3e:23:1d:36,model=rtl8139 -net 
tap,vlan=0,ifname=tap8.0,bridge=xenbr0,script=no -M xenfv

2) If your vif= line in your config specifies a bridge, such as 
''bridge=virbr0'', the ''-net tap'' option to
qemu-dm remains as ''bridge=xenbr0'',
as if it was hard coded. Again, this is an hvm problem. ''xl
create''-ing a pv
domu correctly puts the vif on the requested bridge. (If memory serves, under 
xen 4.1.1, when the vif for an hvm domain was being put on a bridge, I believe 
it was on the bridge requested, so the problem is just with tap.)

3) Specifying vncviewer=1/vncconsole=1 in your config (don''t remember
which
works - I use both) will automatically start a vnc viewer for you when you
''xm
create'' an hvm domain. (Sadly, this never worked for a pv domain. You
have to
use the xm/xl vncviewer domainname command.) This does not work with
''xl
create''.

4) The ''localtime=1'' option in your config is ignored by xl.
This works with
xm. Xl will still honor the rtc_timeoffset option.

5) Anything other than ''videoram=4'' in your config will be
ignored when
starting with xl, but not with xm. You will get an error in your qemu-dm log 
file of the form:

-videoram option does not work with cirrus vga device model. Videoram set to 
4M.

So, are these bugs? or features? Certainly, I see 1) and 2) as bugs.

The rest of the qemu-dm log is unremarkable. My config follows, with python 
code commented out to keep xl happy.

#import os, re
#arch = os.uname()[4]
#if re.search(''64'', arch):
#    arch_libdir = ''lib64''
#else:
#    arch_libdir = ''lib''

name = "winxp"
builder=''hvm''
memory = "768"
uuid = "6c7de04e-df10-caa8-bb2a-8368246225c1"
#ostype = "hvm"
on_reboot = "restart"
on_crash = "restart"
on_poweroff = "destroy"
vcpus = "2"
viridian=1
#
#kernel = "/usr/lib/xen/boot/hvmloader"
kernel = "hvmloader"
acpi=1
apic=1
boot= "cda"
# New stuff
#device_model = ''/usr/'' + arch_libdir +
''/xen/bin/qemu-dm''
#device_model = ''/usr/lib/xen/bin/qemu-dm''
device_model = ''qemu-dm''
#
keymap=''en-us''
localtime=1
#rtc_timeoffset=-14400
#rtc_timeoffset=-18000
pae=1
serial=''pty''
#serial = "/dev/ttyS0"
#   enable sound card support, [sb16|es1370|all|..,..], default none
soundhw=''es1370''
# enable stdvga, default = 0 (use cirrus logic device model)
#stdvga=1
videoram=4
stdvga=0
#usbdevice="mouse"
usbdevice="tablet"
xen_extended_power_mgmt = 0
#
#disk=[ ''tap2:aio:/var/lib/xen/images/winxp,hda,w'', 
''phy:/dev/cdrom,hdc:cdrom,r'' ]
#disk=[
''file:/windows/C/var/lib/xen/images/winxp.sav,ioemu:hda,w'',
''phy:/dev/cdrom,hdc:cdrom,r'' ]
#disk=[ ''file:/var/lib/xen/images/winxp,ioemu:hda,w'', 
''phy:/dev/cdrom,hdc:cdrom,r'' ]
disk=[ ''phy:/dev/disk/by-path/ip-192.168.1.101:3260-iscsi-
iqn.2001-04.com.Dell4550-iqn.2009-09.net.bellsouth.sda:041b7d3f-b008-4367-
b1f2-b4799d15e4cd-lun-1,hda,w'',
''phy:/dev/cdrom,hdc:cdrom,r'' ]
#
vif = [ ''mac=00:16:3e:23:1d:36, script=vif-bridge, bridge = xenbr0, 
model=rtl8139'' ]
#vif = [ ''mac=00:16:3e:23:1d:36, type=ioemu, script=vif-bridge, bridge
=
xenbr0, model=e1000'' ]
#vif = [ ''mac=00:16:3e:23:1d:37, type=netfront, script=vif-bridge,
bridge =
eth0'' ]
#
sdl=0
#vfb = [ ''vnc=1, vnclisten=0.0.0.0, vncunused=0, vncdisplay=3,
vncpasswd= '']
vnc=1
vnclisten="0.0.0.0"
#vnclisten="192.168.1.0"
# set VNC display number, default = domid
vncdisplay=3
# try to find an unused port for the VNC server, default = 1
vncunused=0
vncviewer=1
vncconsole=1
monitor=1
vncpasswd=""


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

On Sat October 29 2011, 1:57:12 AM, jim burns wrote:
> For the remaining problems, note that ''xl create winxp''
creates a qemu-dm
> process with the following parameters:
> 
> qemu-dm -d 8 -domain-name winxp -vnc 0.0.0.0:3 -k en-us -serial pty
> -videoram  4 -boot cda -usb -usbdevice tablet -soundhw es1370 -acpi -vcpus
> 2 -vcpu_avail 0x3 -net nic,vlan=0,macaddr=00:16:3e:23:1d:36,model=rtl8139
> -net tap,vlan=0,ifname=tap8.0,bridge=xenbr0,script=no -M xenfv
Note, starting the domain with ''xm create'' with the same
config results in:

/usr/lib/xen/bin/qemu-dm -d 11 -domain-name winxp -videoram 4 -k en-us -vnc 
0.0.0.0:3 -monitor vc -vcpus 2 -vcpu_avail 0x3 -boot cda -soundhw es1370 -
localtime -serial pty -acpi -usbdevice tablet -net 
nic,vlan=1,macaddr=00:16:3e:23:1d:36,model=rtl8139 -net 
tap,vlan=1,ifname=tap11.0,bridge=xenbr0 -M xenfv

Note, ''xl create'' does not pass the
''-localtime'' option, and its ''-net tap''
specifies ''script=no'', unlike ''xm create''.
Also, for some reason, the vlan
numbers are different between xl and xm.

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

On Sat, 2011-10-29 at 06:57 +0100, jim burns wrote:
> Setup:
> 
> Fedora 15, w/f16''s 3.1.0 (also tried 2.6.40 & 3.0.0)
> xen 4.1.2 (newly upgraded from 4.1.1, from rawhide)
> 
> Since the release notes for 4.1.2 said, in part:
> 
> Fixes/features include:
>  * New XL toolstack
> 
> I decided to test some problems I saw using xl to start a winxp hvm domu
under
> xen 4.1.1, and found that they were still there, and I came up with a
somewhat
> more serious one as well. I''m sure that others can point out more
serious
> problems, but these are the ones that affect me. In all cases, ''xm
create''
> does not have these problems. Domu config at the end of the post.
> 
> New to 4.1.2:
> 
> 1) Starting winxp with xl does not create a vif interface - only a tap one.
> More exactly, the vif is created, but does not get an ipv6 address - it
shows
> up in ''ifconfig -a'', or ''ifconfig
vifn.0'' - and does not get added to the
> bridge. If you are using James'' GPLPV drivers, you end up with no
network
> connectivity, as they use vif, not tap. I''d be surprised if other
pvhvm
> solutions don''t see this also.
I see this with the tip of xen-4.1-testing too but not with
xen-unstable. I''ll see if I can figure out which backport is missing...

[...]
> 2) If your vif= line in your config specifies a bridge, such as 
> ''bridge=virbr0'', the ''-net tap'' option
to qemu-dm remains as ''bridge=xenbr0'',
> as if it was hard coded. Again, this is an hvm problem. ''xl
create''-ing a pv
> domu correctly puts the vif on the requested bridge. (If memory serves,
under
> xen 4.1.1, when the vif for an hvm domain was being put on a bridge, I
believe
> it was on the bridge requested, so the problem is just with tap.)
Similarly I can reproduce this too but only on 4.1.
> 3) Specifying vncviewer=1/vncconsole=1 in your config (don''t
remember which
> works - I use both) will automatically start a vnc viewer for you when you
''xm
> create'' an hvm domain. (Sadly, this never worked for a pv domain.
You have to
> use the xm/xl vncviewer domainname command.) This does not work with
''xl
> create''.
I think this is just a missing feature.
> 
> 4) The ''localtime=1'' option in your config is ignored by
xl. This works with
> xm. Xl will still honor the rtc_timeoffset option.
This option is supposed to control the setting of the RTC to localtime
vs UTC? Another missing feature.

If you fancy having a stab at either of these (I thing they will be
relatively simple to fix) then I''m happy to give some guidance (modulo
going to the airport in a few hours to head out to XenSummit Asia).
> 5) Anything other than ''videoram=4'' in your config will
be ignored when
> starting with xl, but not with xm. You will get an error in your qemu-dm
log
> file of the form:
> 
> -videoram option does not work with cirrus vga device model. Videoram set
to
> 4M.
I''m not sure what''s going on here, since this appears to be a
qemu thing
and that is the same for xend and xl. Perhaps they are choosing
differing graphics card device models? How do the command lines differ
if you use this option?
> 
> So, are these bugs? or features? Certainly, I see 1) and 2) as bugs.
> 
> The rest of the qemu-dm log is unremarkable. My config follows, with python
> code commented out to keep xl happy.
> 
> #import os, re
> #arch = os.uname()[4]
> #if re.search(''64'', arch):
> #    arch_libdir = ''lib64''
> #else:
> #    arch_libdir = ''lib''
> 
> name = "winxp"
> builder=''hvm''
> memory = "768"
> uuid = "6c7de04e-df10-caa8-bb2a-8368246225c1"
> #ostype = "hvm"
> on_reboot = "restart"
> on_crash = "restart"
> on_poweroff = "destroy"
> vcpus = "2"
> viridian=1
> #
> #kernel = "/usr/lib/xen/boot/hvmloader"
> kernel = "hvmloader"
> acpi=1
> apic=1
> boot= "cda"
> # New stuff
> #device_model = ''/usr/'' + arch_libdir +
''/xen/bin/qemu-dm''
> #device_model = ''/usr/lib/xen/bin/qemu-dm''
> device_model = ''qemu-dm''
> #
> keymap=''en-us''
> localtime=1
> #rtc_timeoffset=-14400
> #rtc_timeoffset=-18000
> pae=1
> serial=''pty''
> #serial = "/dev/ttyS0"
> #   enable sound card support, [sb16|es1370|all|..,..], default none
> soundhw=''es1370''
> # enable stdvga, default = 0 (use cirrus logic device model)
> #stdvga=1
> videoram=4
> stdvga=0
> #usbdevice="mouse"
> usbdevice="tablet"
> xen_extended_power_mgmt = 0
> #
> #disk=[ ''tap2:aio:/var/lib/xen/images/winxp,hda,w'', 
> ''phy:/dev/cdrom,hdc:cdrom,r'' ]
> #disk=[
''file:/windows/C/var/lib/xen/images/winxp.sav,ioemu:hda,w'',
> ''phy:/dev/cdrom,hdc:cdrom,r'' ]
> #disk=[ ''file:/var/lib/xen/images/winxp,ioemu:hda,w'', 
> ''phy:/dev/cdrom,hdc:cdrom,r'' ]
> disk=[ ''phy:/dev/disk/by-path/ip-192.168.1.101:3260-iscsi-
> iqn.2001-04.com.Dell4550-iqn.2009-09.net.bellsouth.sda:041b7d3f-b008-4367-
> b1f2-b4799d15e4cd-lun-1,hda,w'',
''phy:/dev/cdrom,hdc:cdrom,r'' ]
> #
> vif = [ ''mac=00:16:3e:23:1d:36, script=vif-bridge, bridge =
xenbr0,
> model=rtl8139'' ]
> #vif = [ ''mac=00:16:3e:23:1d:36, type=ioemu, script=vif-bridge,
bridge =
> xenbr0, model=e1000'' ]
> #vif = [ ''mac=00:16:3e:23:1d:37, type=netfront, script=vif-bridge,
bridge =
> eth0'' ]
> #
> sdl=0
> #vfb = [ ''vnc=1, vnclisten=0.0.0.0, vncunused=0, vncdisplay=3,
vncpasswd= '']
> vnc=1
> vnclisten="0.0.0.0"
> #vnclisten="192.168.1.0"
> # set VNC display number, default = domid
> vncdisplay=3
> # try to find an unused port for the VNC server, default = 1
> vncunused=0
> vncviewer=1
> vncconsole=1
> monitor=1
> vncpasswd=""
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


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

On Sat, 2011-10-29 at 07:17 +0100, jim burns wrote:
> On Sat October 29 2011, 1:57:12 AM, jim burns wrote:
> > For the remaining problems, note that ''xl create
winxp'' creates a qemu-dm
> > process with the following parameters:
> > 
> > qemu-dm -d 8 -domain-name winxp -vnc 0.0.0.0:3 -k en-us -serial pty
> > -videoram  4 -boot cda -usb -usbdevice tablet -soundhw es1370 -acpi
-vcpus
> > 2 -vcpu_avail 0x3 -net
nic,vlan=0,macaddr=00:16:3e:23:1d:36,model=rtl8139
> > -net tap,vlan=0,ifname=tap8.0,bridge=xenbr0,script=no -M xenfv
> 
> Note, starting the domain with ''xm create'' with the same
config results in:
> 
> /usr/lib/xen/bin/qemu-dm -d 11 -domain-name winxp -videoram 4 -k en-us -vnc
> 0.0.0.0:3 -monitor vc -vcpus 2 -vcpu_avail 0x3 -boot cda -soundhw es1370 -
> localtime -serial pty -acpi -usbdevice tablet -net 
> nic,vlan=1,macaddr=00:16:3e:23:1d:36,model=rtl8139 -net 
> tap,vlan=1,ifname=tap11.0,bridge=xenbr0 -M xenfv
> 
> Note, ''xl create'' does not pass the
''-localtime'' option,
that''s the source of one of the missing features. Fixing it should be a
case of adding the option to libxl_domain_build_info in the IDL,
reacting to it in libxl__build_device_model_args_old and
libxl__build_device_model_args_new and parsing the config file option
into it in parse_config_data().
>  and its ''-net tap'' specifies
''script=no'', unlike ''xm create''.
This is expected, with xl the script for tap devices is run via the
hotplug mechanism (i.e. the same as vif) whereas xend apparently runs it
via qemu. Either _should_ work.
> Also, for some reason, the vlan numbers are different between xl and xm.
That''s ok, they are effectively arbitrary and just serve to bind the
"-net nic,..." and "-net tap,..." options to one another
(IOW the vlan
ID needs to be consistent across those two options but is otherwise
unimportant).

Ian.



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

On Mon, 2011-10-31 at 10:50 +0000, Ian Campbell wrote:
> On Sat, 2011-10-29 at 06:57 +0100, jim burns wrote:
> > Setup:
> > 
> > Fedora 15, w/f16''s 3.1.0 (also tried 2.6.40 & 3.0.0)
> > xen 4.1.2 (newly upgraded from 4.1.1, from rawhide)
> > 
> > Since the release notes for 4.1.2 said, in part:
> > 
> > Fixes/features include:
> >  * New XL toolstack
> > 
> > I decided to test some problems I saw using xl to start a winxp hvm
domu under
> > xen 4.1.1, and found that they were still there, and I came up with a
somewhat
> > more serious one as well. I''m sure that others can point out
more serious
> > problems, but these are the ones that affect me. In all cases,
''xm create''
> > does not have these problems. Domu config at the end of the post.
> > 
> > New to 4.1.2:
> > 
> > 1) Starting winxp with xl does not create a vif interface - only a tap
one.
> > More exactly, the vif is created, but does not get an ipv6 address -
it shows
> > up in ''ifconfig -a'', or ''ifconfig
vifn.0'' - and does not get added to the
> > bridge. If you are using James'' GPLPV drivers, you end up
with no network
> > connectivity, as they use vif, not tap. I''d be surprised if
other pvhvm
> > solutions don''t see this also.
> 
> I see this with the tip of xen-4.1-testing too but not with
> xen-unstable. I''ll see if I can figure out which backport is
missing...
23047:4ca13a170482 "libxl: provide full path to vif hotplug script
script" seems like a very plausible candidate, I bet
"script=/etc/xen/scripts/vif-bridge" would function as a workaround.
> [...]
> > 2) If your vif= line in your config specifies a bridge, such as 
> > ''bridge=virbr0'', the ''-net tap''
option to qemu-dm remains as ''bridge=xenbr0'',
> > as if it was hard coded. Again, this is an hvm problem. ''xl
create''-ing a pv
> > domu correctly puts the vif on the requested bridge. (If memory
serves, under
> > xen 4.1.1, when the vif for an hvm domain was being put on a bridge, I
believe
> > it was on the bridge requested, so the problem is just with tap.)
> 
> Similarly I can reproduce this too but only on 4.1.
Actually this one is broken in unstable too.

The handling of leading and trailing whitespace in the vif option seems
to be completely b0rked in xl and e.g. "bridge = virbr1" ends up as
key
"bridge " and key " virbr1". That entire parser (actually,
both of them
-- there''s a whole nother one in main_networkattach!) is a mess.

There''s probably a bandaid which can be applied but really the whole
thing need ripping out and making sensible.

As a workaround in the meantime you can probably avoid whitespace around
the "=" and "," in the vif line.

Ian.


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

On Mon October 31 2011, 11:26:19 AM, Ian Campbell wrote:
> On Mon, 2011-10-31 at 10:50 +0000, Ian Campbell wrote:
> > On Sat, 2011-10-29 at 06:57 +0100, jim burns wrote:
> > > [...]
> > > New to 4.1.2:
> > > 
> > > 1) Starting winxp with xl does not create a vif interface - only
a
> > > tap one. More exactly, the vif is created, but does not get an
ipv6
> > > address - it shows up in ''ifconfig -a'', or
''ifconfig vifn.0'' - and
> > > does not get added to the bridge. If you are using
James'' GPLPV
> > > drivers, you end up with no network connectivity, as they use
vif,
> > > not tap. I''d be surprised if other pvhvm solutions
don''t see this
> > > also.
> > 
> > I see this with the tip of xen-4.1-testing too but not with
> > xen-unstable. I''ll see if I can figure out which backport is
missing...
> 
> 23047:4ca13a170482 "libxl: provide full path to vif hotplug script
> script" seems like a very plausible candidate, I bet
> "script=/etc/xen/scripts/vif-bridge" would function as a
workaround.
Yep - that works. Should have guessed. You have to supply the full path to the 
config file too, or it can''t find it (doesn''t default to
searching /etc/xen).
> > [...]
> > 
> > > 2) If your vif= line in your config specifies a bridge, such as
> > > ''bridge=virbr0'', the ''-net
tap'' option to qemu-dm remains as
> > > ''bridge=xenbr0'', as if it was hard coded.
Again, this is an hvm
> > > problem. ''xl create''-ing a pv domu correctly
puts the vif on the
> > > requested bridge. (If memory serves, under xen 4.1.1, when the
vif
> > > for an hvm domain was being put on a bridge, I believe it was on
> > > the bridge requested, so the problem is just with tap.)> 
> > Similarly I can reproduce this too but only on 4.1.
> 
> Actually this one is broken in unstable too.
> 
> The handling of leading and trailing whitespace in the vif option seems
> to be completely b0rked in xl and e.g. "bridge = virbr1" ends up
as key
> "bridge " and key " virbr1". That entire parser
(actually, both of them
> -- there''s a whole nother one in main_networkattach!) is a mess.
> 
> There''s probably a bandaid which can be applied but really the
whole
> thing need ripping out and making sensible.
> 
> As a workaround in the meantime you can probably avoid whitespace around
> the "=" and "," in the vif line.
> 
Yep - that works too:

root@insp6400 10/31/11  6:31PM:~
[512] > xl create /etc/xen/winxp; brctl show;  ps -A|grep qemu; netstat -tlp|
grep 59; renice -11 `pidof qemu-dm`;  ps -A|grep vncv; ifconfig vif3.0 mtu 
9000 
Parsing config file /etc/xen/winxp
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->000000000017b270
  TOTAL:         0000000000000000->000000002fc00000
  ENTRY ADDRESS: 00000000001015a0
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000009a00
  2MB PAGES: 0x0000000000000131
  1GB PAGES: 0x0000000000000000
Daemon running with PID 6804
bridge name     bridge id               STP enabled     interfaces
virbr0          8000.feffffffffff       yes             tap3.0
xenbr0          8000.0015c5047d4f       no              bond0
 6809 pts/1    S+     0:00                     grep --color=auto qemu
 6758 ?        RLsl   0:00   qemu-dm -d 3 -domain-name winxp -vnc 0.0.0.0:3 -k 
en-us -serial pty -videoram 4 -boot cda -usb -usbdevice tablet -soundhw es1370 
-acpi -vcpus 2 -vcpu_avail 0x3 -net 
nic,vlan=0,macaddr=00:16:3e:23:1d:36,model=rtl8139 -net 
tap,vlan=0,ifname=tap3.0,bridge=virbr0,script=no -M xenfv
tcp        0      0 *:5901                      *:*                         
LISTEN      3283/Xvnc           
tcp        0      0 *:5903                      *:*                         
LISTEN      6758/qemu-dm        
6758 (process ID) old priority 0, new priority -11
 6907 pts/1    S+     0:00                     grep --color=auto vncv
root@insp6400 10/31/11  6:32PM:~
[513] > brctl show
bridge name     bridge id               STP enabled     interfaces
virbr0          8000.feffffffffff       yes             tap3.0
                                                        vif3.0
xenbr0          8000.0015c5047d4f       no              bond0

For 4):

On Mon October 31 2011, 10:56:51 AM, Ian Campbell wrote:
> On Sat, 2011-10-29 at 07:17 +0100, jim burns wrote:
> > On Sat October 29 2011, 1:57:12 AM, jim burns wrote:
> > > For the remaining problems, note that ''xl create
winxp'' creates a
> > > qemu-dm process with the following parameters:
> > > 
> > > qemu-dm -d 8 -domain-name winxp -vnc 0.0.0.0:3 -k en-us -serial
pty
> > > -videoram  4 -boot cda -usb -usbdevice tablet -soundhw es1370
-acpi
> > > -vcpus 2 -vcpu_avail 0x3 -net
> > > nic,vlan=0,macaddr=00:16:3e:23:1d:36,model=rtl8139 -net
> > > tap,vlan=0,ifname=tap8.0,bridge=xenbr0,script=no -M xenfv> 
> > Note, starting the domain with ''xm create'' with the
same config results
> > in:
> > 
> > /usr/lib/xen/bin/qemu-dm -d 11 -domain-name winxp -videoram 4 -k en-us
> > -vnc 0.0.0.0:3 -monitor vc -vcpus 2 -vcpu_avail 0x3 -boot cda -soundhw
> > es1370 - localtime -serial pty -acpi -usbdevice tablet -net
> > nic,vlan=1,macaddr=00:16:3e:23:1d:36,model=rtl8139 -net
> > tap,vlan=1,ifname=tap11.0,bridge=xenbr0 -M xenfv
> > 
> > Note, ''xl create'' does not pass the
''-localtime'' option,
> 
> that''s the source of one of the missing features. Fixing it should
be a
> case of adding the option to libxl_domain_build_info in the IDL,
> reacting to it in libxl__build_device_model_args_old and
> libxl__build_device_model_args_new and parsing the config file option
> into it in parse_config_data().
Hopefully, the fix for 3) (vncconsole=1) is just as simple.
> >  and its ''-net tap'' specifies
''script=no'', unlike ''xm create''.
> 
> This is expected, with xl the script for tap devices is run via the
> hotplug mechanism (i.e. the same as vif) whereas xend apparently runs it
> via qemu. Either _should_ work.
> 
> > Also, for some reason, the vlan numbers are different between xl and
xm.
> 
> That''s ok, they are effectively arbitrary and just serve to bind
the
> "-net nic,..." and "-net tap,..." options to one
another (IOW the vlan
> ID needs to be consistent across those two options but is otherwise
> unimportant).
Thanx for the explanations.

On Mon October 31 2011, 10:50:32 AM, Ian Campbell wrote:
> > 5) Anything other than ''videoram=4'' in your config
will be ignored when
> > starting with xl, but not with xm. You will get an error in your
qemu-dm
> > log file of the form:
> > 
> >
> > -videoram option does not work with cirrus vga device model. Videoram
> > set to  4M.
> 
> I''m not sure what''s going on here, since this appears to
be a qemu thing
> and that is the same for xend and xl. Perhaps they are choosing
> differing graphics card device models? How do the command lines differ
> if you use this option?
With videoram=8, and ''xm create'', you get what you expect:

 6026 ?        RLl    0:00     /usr/lib/xen/bin/qemu-dm -d 2 -domain-name 
winxp -videoram 8 -k en-us -vnc 0.0.0.0:3 -monitor vc -vcpus 2 -vcpu_avail 0x3 
-boot cda -soundhw es1370 -localtime -serial pty -acpi -usbdevice tablet -net 
nic,vlan=1,macaddr=00:16:3e:23:1d:36,model=rtl8139 -net 
tap,vlan=1,ifname=tap2.0,bridge=xenbr0 -M xenfv

Thanx for the thorough review.

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

On Mon, 2011-10-31 at 19:00 -0400, jim burns wrote:
> > that''s the source of one of the missing features. Fixing it
should
> be a
> > case of adding the option to libxl_domain_build_info in the IDL,
> > reacting to it in libxl__build_device_model_args_old and
> > libxl__build_device_model_args_new and parsing the config file
> option
> > into it in parse_config_data().
> 
> Hopefully, the fix for 3) (vncconsole=1) is just as simple. 
Rather than having libxl__build_device..._args handling things I think
you would want to call libxl_vncviewer_exec from xl, at roughly the same
sort of place as libxl_console_exec is called when -c is passed to
create, that is wherever autoconnect_console is called.

(aside: would a command line option similar to -c but for VNC be as/more
useful than the vncauto thing in the cfg?).

Ian.


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

On Tue November 1 2011, 9:49:35 PM, Ian Campbell wrote:
> On Mon, 2011-10-31 at 19:00 -0400, jim burns wrote:
> > > that''s the source of one of the missing features. Fixing
it should
> > 
> > be a
> > 
> > > case of adding the option to libxl_domain_build_info in the IDL,
> > > reacting to it in libxl__build_device_model_args_old and
> > > libxl__build_device_model_args_new and parsing the config file
> > 
> > option
> > 
> > > into it in parse_config_data().
> > 
> > Hopefully, the fix for 3) (vncconsole=1) is just as simple.
> 
> Rather than having libxl__build_device..._args handling things I think
> you would want to call libxl_vncviewer_exec from xl, at roughly the same
> sort of place as libxl_console_exec is called when -c is passed to
> create, that is wherever autoconnect_console is called.
> 
> (aside: would a command line option similar to -c but for VNC be as/more
> useful than the vncauto thing in the cfg?).
>
Hmm - I suppose it would be more symmetric. You have ''-c'' for
''xm/xl create'',
corresponding to ''xm/xl console''. I suppose
''-vnc'' (or whatever) would then
correspond to ''xm/xl vncviewer''.

I personally prefer the ''vncauto thing'', as I always want to
see the boot
msgs, and I don''t want to miss any because I forgot to add the option,
and
have to do a ''xm/xl vncviewer/console'' after some of the msgs
have scrolled
away. (It''s amazing how some stdout/errout msgs never make it into a
log
file.)


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

On Mon, 31 Oct 2011, Ian Campbell wrote:
> > 3) Specifying vncviewer=1/vncconsole=1 in your config (don''t
remember which
> > works - I use both) will automatically start a vnc viewer for you when
you ''xm
> > create'' an hvm domain. (Sadly, this never worked for a pv
domain. You have to
> > use the xm/xl vncviewer domainname command.) This does not work with
''xl
> > create''.
> 
> I think this is just a missing feature.
> 
Nope, it should work. IanJ implemented this feature a while back.
 

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

On 3 November 2011 07:46, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Mon, 31 Oct 2011, Ian Campbell wrote:
>> > 3) Specifying vncviewer=1/vncconsole=1 in your config
(don''t remember which
>> > works - I use both) will automatically start a vnc viewer for you
when you ''xm
>> > create'' an hvm domain. (Sadly, this never worked for a pv
domain. You have to
>> > use the xm/xl vncviewer domainname command.) This does not work
with ''xl
>> > create''.
>>
>> I think this is just a missing feature.
>>
>
> Nope, it should work. IanJ implemented this feature a while back.
I doesn''t work to me using xl. I am obliged to do xl vncviewer
<domain_id>
once the domU has started.
-- 
Flavio

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

On Thu, 2011-11-03 at 04:39 -0400, Flavio wrote:
> On 3 November 2011 07:46, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Mon, 31 Oct 2011, Ian Campbell wrote:
> >> > 3) Specifying vncviewer=1/vncconsole=1 in your config
(don''t remember which
> >> > works - I use both) will automatically start a vnc viewer for
you when you ''xm
> >> > create'' an hvm domain. (Sadly, this never worked for
a pv domain. You have to
> >> > use the xm/xl vncviewer domainname command.) This does not
work with ''xl
> >> > create''.
> >>
> >> I think this is just a missing feature.
> >>
> >
> > Nope, it should work. IanJ implemented this feature a while back.
> I doesn''t work to me using xl. I am obliged to do xl vncviewer
<domain_id>
> once the domU has started.
You are correct, I think what Stefano is thinking of is when IanJ
implemented the xl vncviewer command. There is no support in xl (that I
can see) for setting "vncconsole=1" in the domain configuration file
and
having that autospawn vncviewer on create. Patches for this feature
would be very welcome.

Ian.


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

On Thu, 3 Nov 2011, Ian Campbell wrote:
> On Thu, 2011-11-03 at 04:39 -0400, Flavio wrote:
> > On 3 November 2011 07:46, Stefano Stabellini
> > <stefano.stabellini@eu.citrix.com> wrote:
> > > On Mon, 31 Oct 2011, Ian Campbell wrote:
> > >> > 3) Specifying vncviewer=1/vncconsole=1 in your config
(don''t remember which
> > >> > works - I use both) will automatically start a vnc
viewer for you when you ''xm
> > >> > create'' an hvm domain. (Sadly, this never
worked for a pv domain. You have to
> > >> > use the xm/xl vncviewer domainname command.) This does
not work with ''xl
> > >> > create''.
> > >>
> > >> I think this is just a missing feature.
> > >>
> > >
> > > Nope, it should work. IanJ implemented this feature a while back.
> > I doesn''t work to me using xl. I am obliged to do xl
vncviewer <domain_id>
> > once the domU has started.
> 
> You are correct, I think what Stefano is thinking of is when IanJ
> implemented the xl vncviewer command. There is no support in xl (that I
> can see) for setting "vncconsole=1" in the domain configuration
file and
> having that autospawn vncviewer on create. Patches for this feature
> would be very welcome.
 
yes, my mistake.

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