Wine automated testing update
Francois Gouget
fgouget at codeweavers.com
Thu Jun 21 09:21:48 CDT 2012
On Wed, 1 Feb 2012, Jeremy White wrote:
[...]
> However, Alexandre has persuaded me that we should first explore
> integrating the dotest.sh functionality into the existing WineTestBot,
> as that would allow us to have a very simple clean web page, and would
> also allow us to integrate most cleanly with Alexandre's back end tools.
>
> Of course, WineTestBot is Perl code, and my Perl fu is low. So I have
> recently asked Francois to help with that effort as well.
>
> So the basic plan is as follows:
[...]
> 2. If so, modify WineTestBot to use qemu instead of vmware.
> (This is 'easy' because the WineTestBot code nicely isolates
> the VM functions, but 'hard', because VMWare provides some
> APIs that may have to be replicated).
So I have finally found the time to get started on this. Yay!
It's not done yet but I figure it's time for me to give a status report
and ask some questions.
--- LibVirt
I updated the Perl scripts to remove the dependency on VMware. Now I use
libvirt which is a virtualization API that supports multiple
virtualization technologies such as KVM/QEMU, but also VirtualBox, Xen
and even VMware. libvirt also makes it possible to control VMs on remote
boxes so we can distribute the load over multiple machines. For more
details see the project's web site:
http://libvirt.org/
--- Host / VM communication
One piece that's missing is the ability to copy files from/to a VM and
to run specific commands in a VM. This was provided by VMware's VIX API
combined with a guest agent. See VMCopyFileFromHostToGuest() and
VM::RunScriptInGuest() on the following page for instance:
http://www.vmware.com/support/developer/vix-api/vix111_reference/index2.html
All replacements involve installing some application in the Windows VM.
So given that we want to run Winetest too I have the following
requirements:
* The application should run on everything from Windows 8 down to NT4.
* It should not bring in dependencies that would modify the behavior of
Windows. So anything that depends on installing .Net or upgrading
standard dlls located in c:\windows\system32 is out.
* Ideally it should also have a 64bit version so we can have
64bit-only Windows VMs.
So I looked for a replacement but came away not entirely satisfied:
* There is some talk of a QEmu Guest Agent but as far as I can tell
it's just vaporware. If someone knows more I'd be interested (even if
it would tie us to QEmu).
http://wiki.qemu.org/Features/QAPI/GuestAgent
* There is the BuildBot slave which probably provides the functionality
we need. But it is implemented in Python which only works on Windows
XP and later, and comes as an MSI installer. I did not check exactly
how to interface with it.
http://trac.buildbot.net/wiki/RunningBuildbotOnWindows
* There's Cygwin's OpenSSH server which would give us what we need
through scp and ssh. Cygwin does not install on NT4 and I'm not
convinced it's really free of side-effects. In particular copying
the cygwin directory to another computer does not seem to work.
http://cygwin.com/install.html
* There's more limited OpenSSH installations derived from Cygwin
but I'm not sure they're much better on the side-effects side.
http://sshwindows.sourceforge.net/download/
* For my own Windows VMs (see the fg-xxx VMs on test.winehq.org), what
I use is a Windows implementation of netcat.
http://joncraton.org/blog/46/netcat-for-windows
I essentially run it in a batch that does:
REM Receive winetest and how to invoke it
nc95 -l -p%port% >app.exe
nc95 -l -p%port% >cmdline.bat
REM Run winetest, sending its output to the client
nc95 -l -p%port% -e .\cmdline.bat
I'm not entirely satisfied with it (and not because netcat is
totally insecure, the VMs are behind firewalls anyway). Rather it's
because it's not very flexible and because it has race conditions
(which I work around with pauses on the client side). I could make it
more flexible with something like:
:start
nc95 -l -p%port1% >cmd.bat
nc95 -l -p%port1% -e .\cmd.bat
goto start
And put more nc95 commands running on a second port in cmd.bat.
* Modified Windows netcat. I'd like to be able to run a netcat server
so that on the client side I could do:
(
echo "write c:/winetest.exe"
cat winetest.exe
) | netcat $host $port
echo "run c:/winetest.exe my options here" |
netcat $host $port >winetest.log
The server would see the command on the first line and do the
relevant action.
--- Network trouble
I'm having trouble getting the network to work fine in the QEmu VMs.
Eventually I discovered that if I bridged to eth0 then it's just the
communication between the host and the VM that does not work.
Communication with other machines on the LAN or with the Internet works.
However that's going to be a big problem to send the jobs to the VMs
(see previous section, plus the dhcp and dns is also running on the host
in my case).
Now, rather than bridge to eth0 what I'd want on my machine is to bridge
to tap0, a local network where I have all my VMware VMs.
What I typically see if I ping the host from the VM is that the echo
requests go out and the echo replies are sent. But ping on the VM sees
nothing. It could be a firewalling issue though my VMware VMs on the
same network work fine.
--- Patches
My code is far from ready for commits but I stumbled upon a few fixes.
Where should I send those?
--- Build VM
The installation instructions mention setting up a 'Wine build VM' but
are short on details. Is it actually supposed to be a VM. What name?
Identified through the 'Type' field in the VMs table?
--- Miscellaneous
* In Engine.pl, HandleBuildNotification() calls a
${ProjectName}RetrieveBuild.pl script which concerns me because there
is no such script. There is a WineRunBuild.pl script that could match
though. Still that indicates the Git code may not be exactly what's
running on the current WineTestBot. Does anyone know more?
* The virtio disk and network drivers appear to be a must. Replacing
the default vga emulation with the cirrus one makes it possible to
suspend / hibernate the VM (which is probably useless but still
instills more confidence to me). Switching to vmware seems to give
the best performance but Libvirt does not recognize it :-(
It looks like the XML schema is simply being out of date. Does
anyone know more?
Still on the subject of optimizing Windows to work with QEmu, does
anyone know if it's possible to expose the full capabilities of the
graphics card to the VM? By declaring the graphics card as
'passthrough' maybe? That would be nice for Direct3D but I'm not
getting my hopes up :-(
--
Francois Gouget <fgouget at codeweavers.com>
More information about the wine-devel
mailing list