xml_utils_unittest - Fix problem running unittests in parallel

Turns out that the unittest checks for certain files
in /tmp, that are being used by other unittests.
Change the prefix in a way that it's unique for this
unittest, so we avoid checking clashes.

Signed-off-by: Chris Evich <cevich@redhat.com>
Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
qemu:cpuid: fix link warning 'cannot find entry symbol _start'

Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Tested-by: Eduardo Habkost <ehabkost@redhat.com>
qemu:cpuid: link kernel sections explicitly

When qemu boots multiboot kernel without explicit *_addr fields
(i.e. when bit 16 in flags is cleared), it loads all sections
marked as LOAD and gcc by default may generate elf file with
a big hole between these sections, which results in passing a
large buffer to multiboot loader that reads it via mmio and
it could take ~15 sec for 128Mb buffer (in this case).

Fix it on kernel side, by explicitly specifing sections link
order/positions to avoid hole between .text and .note sections

Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Tested-by: Eduardo Habkost <ehabkost@redhat.com>
run: Fix wrong param assignment (image_type/image_format)

Paolo spotted a mistake I've made - in fact when we
select an image type that is not in one of our variants,
the correct param name is image_format.

CC: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
run: Fix wrong param assignment (nic_type/nic_model)

Paolo spotted another mistake I've made - in fact when we
select an nic model that is not in one of our variants,
the correct param name is nic_model.

CC: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
Rename default VM from vm1 to virt-tests-vm1

Using 'vm1' for the libvirt tests is a bit too generic IMO. Could
collide with a pre-existing VM, or just cause momentary user
confusion, as it did for me :)

Additionally remove all the instances where the old name was hardcoded
as a fallback. The QEMU tests don't use similar logic, and AFAICT it's
fair to assume that main_vm will always be specified, since it is
present in the shared base.cfg.

Signed-off-by: Cole Robinson <crobinso@redhat.com>
libvirt: Disable many checks for domname tests

The domname tests largely only test virsh + libvirt API parameter
validation, there is very little qemu interraction. So it is largely
overkill to

- Encode a video file
- Verify that each guest is still alive after each test
- Unconditionally kill the VM after each test
- Run qemu-img check after each test

With these enabled, the default set of libvirt tests via ./run take
only about a minute on my machine, previously it was over 5 minutes.

Signed-off-by: Cole Robinson <crobinso@redhat.com>
base.cfg: Document skip_image_processing

Signed-off-by: Cole Robinson <crobinso@redhat.com>
standalone_test: Remove unused import

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
run: Introduce test job stats display v2

It is frequently useful to know how long a total
test sequence took to run, how many tests passed
and failed total, and the success rate, specially
in longer test jobs. Create a report function
that displays this info. As an example, here it's
how it looks:

./run -t qemu --tests migrate.with_reboot
SETUP: PASS (1.30 s)
DATA DIR: /home/lmr/virt_test
DEBUG LOG:
/home/lmr/Code/virt-test.git/logs/run-2013-02-18-16.46.48/debug.log
TESTS: 4
(1/4) migrate.with_reboot.tcp: PASS (51.62 s)
(2/4) migrate.with_reboot.unix: PASS (52.86 s)
(3/4) migrate.with_reboot.exec: FAIL (409.05 s)
(4/4) migrate.with_reboot.fd: PASS (59.65 s)
TOTAL TIME: 573.19 s (09:33)
TESTS PASSED: 3
TESTS FAILED: 1
SUCCESS RATE: 75.00 %

Make this reporting function print both to stdout and
to the debug log.

Changes from v1:

We have conventioned that TestNAError (SKIP) and
TestWarning (WARN) are not failures, considering that
in the first case, the case wasn't executed, and in
the second case, a condition happened, but it is not
alarming enough to consider the test as failed. Also,
it is important to mention that this job report is there
only as quick reference for the person running the
tests, not a substitute for analyzing test results.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
qemu/tests/cfg/kernel_install.cfg: Uncoment all variants

It is not a problem that they are all uncommented. Just
use the variant you need.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
qemu/tests/kernel_install.py: Fix typos and control file location

The control file location now can be determined using
the data dir module.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
shared/deps: Add patched boottool

Current autotest upstream has a strange bug that makes
setting up a boot entry on a guest system not possible.

Ship this file with a patch to the problem for the time
being. We plan on getting rid of it as soon as autotest
0.15.X rpms are packaged and ubiquitous.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
shared/deps: Add patched test kernel install autotest client module

Ship this modified version of the autotest module
necessary to execute the kernel install test. As
this module utility mostly for virt-tests, the original
client module will be dropped from autotest-client-tests.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
virttest.utils_test: Numerous fixes to the run_autotest function

In order to make the kernel install (and other autotest
tests) viable again even when using the autotest client
from the system wide install (rpm), perform a number of
changes in the run_autotest function:

 * Locate the needed autotest pieces on a system wide
   install
 * Set the destination autotest path in the guest to
   '/usr/local/autotest', unconditionally
 * Modify the global_config.ini to be copied to the
   guest to honor the dest autotest path
 * Send a patched version of the boottool to the guest
   instead of the one provided by autotest
 * Send a patched version of the kernel install
   autotest client module to the guest instead of
   the one provided by autotest

Although not quite what we want, it is the only way
to work around the current autotest 0.14.3 rpm install
limitations. We'd like to drop the modified versions
ASAP.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
guest kernel install: Auto configure kernels

If no kernel configure file was provided, just let
autotest auto configure the kernel, based on the
guest current running kernel config.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
qemu/tests/cfg/kernel_install.cfg: Improve comments

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
guest kernel install test: Use install_what_provides directly

That will produce the same outcome as calling provides
and then using the output to install the package.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
guest kernel install: Use a more robust way to install koji/brew pkgs

Since we might have problems checking for packages that
provide a given file, let's try to be more robust and
provide the names of the koji and brew providers directly.

Although slightly less flexible, the package names are
not expected to change soon, and this avoids yum problems
fetching up information (SSL errors).

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
guest kernel install: Hardcode brew/koji pkg names

Fedora 18 has shown us that using yum.YumBase() is
not so safe as we previously thought. The CLI app
does a lot of housekeeping that we've been unable
to replicate using the parts of the yum API that we
could've figured out.

Therefore, be more direct and hardcode the names
of the packages that might provide brew or koji.
This way, when we call install() on them, we're
invoking the CLI, that will do all the housekeeping
and avoid errors.

Also, handle better errors when we couldn't get
a package information from brew, raise an error
much more understandable for the user.

signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>