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

[jim burns <jim_burn@xxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel