virt: fix localhost migration

Autotest always uses "-incoming tcp:0:$port" to start dest vm,
and migrate with "migrate -d tcp:localhost:$port",
or "migrate -d tcp:$dest_host:$port"

Upstream qemu already supports IPv6 migration, current autotest
would fail to migrate in localhost.

'localhost' has multiple aliases (::1 and 127.0.0.1) in /etc/hosts.
getaddrinfo() returns an address list, "::1" is the first item
of the list, "127.0.0.1" is the second item. First available
addr will be choosen to connect. But "0" will be parsed to 127.0.0.1
It caused localhost migration fails, multiple host migration
is fine.

For resolving localhost migration issue, we can listen by
'-incoming tcp:localhost:$port' and migrate by 'migrate
-d tcp:localhost:$port'. Or listen by '-incoming tcp:0:$port'
and migrate by 'migrate -d tcp:0:$port'
This patch uses second resolution.

Signed-off-by: Amos Kong <akong@redhat.com>
boottool: Don't even try to build if popt.h is missing

Boottool does require popt.h at build time. So, if this
include is not present, don't even bother trying to build
grubby.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
virt.trans_hugepage_swapping: Update env method

The test was still using an old API and needed update.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
install_server: fix repair

If we do not pass a profile to install_host(), we end up un-setting the
host's profile in cobbler, which causes subsequent sync's to throw
exceptions. It makes sense in this situation to use the existing profile
from the system. But rather than call this repeatedly, pull it up before
we start the install.

Found during verify/repair testing.

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Fix boottool on ppc64

When trying to run a simple job with the new boottool, I get:

  Traceback (most recent call last):
    File "/usr/local/autotest/job.py", line 1082, in _run_step_fn
      exec('__ret = %s(*__args, **__dargs)' % fn, local_vars, local_vars)
    File "<string>", line 1, in <module>
    File "/usr/local/autotest/control.autoserv", line 16, in boot_kernel
      host.cleanup_kernels()
    File "/usr/local/autotest/shared/hosts/base_classes.py", line 656, in cleanup_kernels
      boot_info = self.bootloader.get_entries()
    File "/usr/local/autotest/tools/boottool", line 998, in get_entries
      entries[entry["index"]] = entry
  KeyError: 'index'

This is because boottool::get_entries() does:

  raw = self.get_info()
  ...
  for entry_str in raw.split("\nindex"):

Which doesn't split off the first entry if the raw string starts off with
"index". This then results in "indexindex 0" being the first string, causing
the parse error above.

If I change that split to be regex based off starting with index, I get
further, but then still error out:

  Traceback (most recent call last):
    File "/usr/local/autotest/job.py", line 1082, in _run_step_fn
      exec('__ret = %s(*__args, **__dargs)' % fn, local_vars, local_vars)
    File "<string>", line 1, in <module>
    File "/usr/local/autotest/control.autoserv", line 16, in boot_kernel
      host.cleanup_kernels()
    File "/usr/local/autotest/shared/hosts/base_classes.py", line 658, in cleanup_kernels
      for boot in boot_info.itervalues()]
  KeyError: 'kernel'

This is because my grubby --info outputs:

index=1
non linux entry
...
index=4
non linux entry
index=5
non linux entry

And boottool seems to assume that all entries are valid.

I think it is appropriate to skip these entries explicitly.

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
boottool: Fix incorrect regexp on get_entries() code

If we use

        for entry_str in re.split("^index", raw):

on raw grubby --info=ALL output, we will end up with a
single string, making boottool --info=ALL to return
an empty set, making autotest to wipe out all kernels
of a machine upon execution of the Hosts.cleanup_kernels()
method. Let's fix the regexp to be "index".

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
hosts.base_classes: Fix a bug in the cleanup_kernels code

The heuristics used to determine which kernel versions are
referenced by the bootloader configuration are no longer
valid for the newer grubby-based code - now that the entries
dict retorns a full kernel path, such as

/boot/vmlinuz-3.3.1-3.fc17.x86_64

We need to use the basename, then strip 'vmlinuz-', rather
than just strip 'vmlinuz-' from the resulting string. This
bug fixes a condition where the used kernels were being
incorrectly determined, hence autotest would go and remove
all kernels of a machine.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
kernel/kernel_config: Code style fixes

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
client.kernel_config: Fall back to running config as oldconfig

If we couldn't find any of the user provided configuration
items when no config file is explicitly provided, fall back
to the running kernel config, as it's more likely that we
will end up with a functional kernel at the end of the process
(defconfig might miss important modules, such as networking).

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
install-autotest-server.sh: Make SELinux permissive mode permanent

As SELinux is turned off only temporarily with
'setenforce 0', the next time the autotest server is
rebooted, the SELinux related problems will start to
pop out again, so change default enforcing mode to
permissive.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
install-autotest-server: Improve git management

Add the autotest repo as the origin for the git repo,
making the autotest home dir to actually behave as
a clone of the upstream tree.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
virt_utils.install_host_kernel: Pass config only if available

With recent changes to the kernel config selection, now
we can omit the kernel configure file. So, only call the
configure method if we have the config, otherwise let it
default to the running config of our virtualization host.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
virt_utils.install_host_kernel: Pass koji_build to KojiPkgSpec

Turns out we were not passing the koji_build to KojiSpec,
so if one specifies a particular build, it'll be ignored
by our code. So fix that bug.

Now, users specifying host_kernel_koji_build will have
their settings honored.

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