On Tue, Jan 14, 2014 at 12:33:05PM -0200, Ruda Moura wrote:
> On Mon, Jan 13, 2014 at 05:08:11PM -0200, Eduardo Habkost wrote:
>
> > I have just noticed that the cpuid.py check for QEMU error messages was
> > broken by:
> >
> > commit cdeed8a35629564c9790e9b19d6442bc2108ae7c
> > Author: Ruda Moura <[email protected]>
> > Date: Mon Dec 16 17:16:37 2013 -0200
> ...
> > Now I am getting failures instead of SKIP results. For example:
> >
> > 13:46:42 ERROR| FAIL
> > type_specific.qemu_cpu.cpuid.full_dump.default.default.machine.rhel.rhel640.kvm.cpu.amd.athlon.unknown.rhel.6.6_4
> > -> VMStartError: VM 'virt-tests-vm1' failed to start: Qemu is defunct.
> > Qemu output:
> > warning: host doesn't support requested feature: CPUID.80000001H:EDX.mmxext
> > [bit 22]
> > warning: host doesn't support requested feature:
> > CPUID.80000001H:EDX.3dnowext [bit 30]
> > warning: host doesn't support requested feature: CPUID.80000001H:EDX.3dnow
> > [bit 31]
> > qemu-kvm: Host's CPU doesn't support requested features
> >
> > The error above was supposed to be caught by the following code on
> > cpuid.py:
> >
> > try:
> > out = get_guest_cpuid(
> > self, cpu_model, cpu_model_flags + ',enforce',
> > extra_params=dict(machine_type=machine_type, smp=1))
> > except virt_vm.VMStartError, e:
> ^^^^^^^^^^^^
> So if you changed from Create to Start then e.output won't have
> the string you are looking for.
What was the reason to choose "e.output" for VMStartError and "e.reason"
for VMCreateError? If the "output" field existed on both classes, I
could simply catch both exceptions.
> > if "host doesn't support requested feature:" in e.output \
> > or ("host cpuid" in e.output and
> > ("lacks requested flag" in e.output or
> > "flag restricted to guest" in e.output)):
> > raise error.TestNAError(
> > "Can't run CPU model %s on this host" %
> > (full_cpu_model_name))
> > else:
> > raise
>
> VMStartError will never raise with "host doesn't..."
> But I'm not sure if it's OK to catch CreateVMError and VMStartError
When I wrote the code above, VMStartError was raised and had all the
information I need. What I don't know is: was this change introduced on
purpose?
>
> except (virt_vm.CreateVMError, virt_vm.VMStartError) as e:
> if "host doesn't support requested feature:" in e.output \
> ...
>
> Or just to keep catching CreateVMError and ignore VMStartError.
> It depends, more talk.
>
> > I am trying to understand how the new code is supposed to work:
>
> It calls is_defunct() to walk in the process tree, started
> to setup qemu environment, and tries to catch qemu in defunct
> state, which is just grep by <defunct> string for each process, and
> raises VMStartError with string "Qemu is defunct.\nQemu output:\n%s"
> attached.
>
> The initial purpose is to catch qemu dead in special situations,
> when virttest runs in sandbox ON (the default for a time) and
> there was not a previous white listed system call for a valid
> test. Say for running the 'audio.py' test in Fedora, virt-test was
> putting qemu in defunct state (is_alive can't detect)
>
> Is_alive is a test from the framework to check if
> the process tree for the test is sane.
Why is it so important to differentiate alive=False,defunct=False from
alive=False,defunct=True? Why not just make is_alive() return False in
case the process is defunct?
In my test case, I don't care at all if QEMU was defunct or not. QEMU
becoming defunct is not QEMU's fault: it is its parent's fault (in other
words, virt-test's fault for not wait()ing for it after it has
terminated). All I care about is catching cases when QEMU terminates,
and getting the stdout and stderr output when that happens.
>
> > The above QEMU error message was always caught by the
> > self.process.is_alive() check, but now the is_defunct() check is
> > catching it.
> >
> > So, is the is_alive() check obsolete? If it is not, why isn't it being
> > triggered anymore on my test case?
>
> No, absolute not! :) is_alive() cannot detect qemu in defunct state,
> just it.
But, is it really possible to have QEMU _not_ in defunct state if it is
not alive? In other words: is it possible to have both is_alive() and
is_defunct() returning False at the same time?
>From the results I am seeing, it looks like virt-test is not wait()ing
QEMU when it aborts, and QEMU will always be in defunct state on those
cases.
That's why I am not sure yet if the new behavior is on purpose. If you
tell me the API won't change and I should look for VMCreateError, I will
happily change the test code.
--
Eduardo
_______________________________________________
Virt-test-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virt-test-devel
