Problems with 'xl create winxp' (hvm) on xen 4.1.2 (also affects GPLPV)

Problems with 'xl create winxp' (hvm) on xen 4.1.2 (also affects GPLPV)

[jim burns]

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=""

Re: Problems with 'xl create winxp' (hvm) on xen 4.1.2 (also affects GPLPV)

[jim burns]

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.

Re: Problems with 'xl create winxp' (hvm) on xen 4.1.2 (also affects GPLPV)

[Ian Campbell]

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

Re: Re: Problems with 'xl create winxp' (hvm) on xen 4.1.2 (also affects GPLPV)

[Ian Campbell]

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.

Re: Problems with 'xl create winxp' (hvm) on xen 4.1.2 (also affects GPLPV)

[Ian Campbell]

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.

Re: Problems with 'xl create winxp' (hvm) on xen 4.1.2 (also affects GPLPV)

[jim burns]

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.

Re: Problems with 'xl create winxp' (hvm) on xen 4.1.2 (also affects GPLPV)

[Ian Campbell]

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.

Re: Problems with 'xl create winxp' (hvm) on xen 4.1.2 (also affects GPLPV)

[jim burns]

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.)

Re: Problems with 'xl create winxp' (hvm) on xen 4.1.2 (also affects GPLPV)

[Stefano Stabellini]

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.

Re: Re: [Xen-devel] Problems with 'xl create winxp' (hvm) on xen 4.1.2 (also affects GPLPV)

[Flavio]

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

Re: [Xen-users] Re: Problems with 'xl create winxp' (hvm) on xen 4.1.2 (also affects GPLPV)

[Ian Campbell]

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.

Re: [Xen-users] Re: Problems with 'xl create winxp' (hvm) on xen 4.1.2 (also affects GPLPV)

[Stefano Stabellini]

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.