[Xen-devel] [PATCH OSSTEST v4 00/25] add distro domU testing flight

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

Hi,

It's been a long time since v3 of this series, which was
http://article.gmane.org/gmane.comp.emulators.xen.devel/224415. That
contains the background which I won't repeat here.

Since then I have done the big rebase, addressed the review feed back
from last time (I think!) and added a new feature which is a bit
unrelated but uses the new ability to do d-i based installs to test
qcow, vhd and raw file images in the main flight.

There are some patches in here which I think will be useful to the Intel
folks doing the nested virt testing, specifically the refactoring of how
overlays and ssh host keys are done will be useful for installing a
guest to be treated as the L1 host. LongTao, I've CCd you only on the 3
patches which I think will be of interest instead of the full 24 patch
series.

For the benefit of that work it would be good to get at least the
precursor cleanup/refactoring patches into good shape and into the tree
sooner rather than later.

I've run this as an adhoc job on the Cambridge instance, the results of
which are at:
http://www.chiark.greenend.org.uk/~xensrcts/logs/36995/

The failures mainly seem to be some sort of proxy issue returning old
data (similar to what used to happen to mg-debian-installer-update), so
we boot an older d-i kernel+initrd and end up unable to find any kernel
modules. I've tried to workaround this with a patch near the end
"ts-debian-di-install: Use ftp.debian.org directly", the latter I'm not
sure how to handle other than by bashing the local proxy over the head.

On a small number I see "The installer failed to download a file from
the mirror." messages, which might be the cache/proxy or might be an
actual Debian issue.

On the one armhf attempt which didn't suffer from the first problem
(daily netboot based) it seems the kernel didn't actual halt when
shutdown, which is likely to be a real Debian kernel bug.

I've also run an adhoc xen-unstable test of the new jobs there, results
at http://www.chiark.greenend.org.uk/~xensrcts/logs/37011/ the
interesting jobs are *-pvgrub, *-pygrub for the bootloader tests and
*-{qcow2,raw,vhd} for the image format stuff, LVM is tested by the
existing -{xl,libvirt} jobs.

Results are a bit of a mixed bag. 64-bit pvgrub worked, but 32-bit
pvgrub failed due to Debian installing a non-PAE kernel (which cannot be
booted), that's probably a bug in the preseeding. The pygrub test
passed.

-qcow2 and -vhd tests passed except the armhf one which couldn't find
the appropriate vmlinuz-xen because mg-debian-installer-update doesn't
create it, and the Wheezy baseline doesn't support running as a Xen
guest on ARM anyway. I could suppress this in make-flight until the
Jessie upgrade.

The -raw tests all failed due to a timeout doing:
        dd if=/dev/zero of=/var/lib/xen/images/debian/disk.raw bs=1M count=10000
        
I'm unclear if it timed out after 30 (as the code seems to say) or 60
(as the logs seem to say) but either way something obviously needs
adjusting. I just tried it on my local test box and it took 1m20s and
reported 130 MB/s. I've appended an as yet untested patch which assumed
100 MB/s and calculates a timeout from that.

I could switch to using "count=1 seek=10000" to create a sparse file,
which should be pretty much instantaneous, but allocating the whole
backing file seemed like a good idea.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel