Hi Michael,
actually it's necessarily. qemu-kvm only put this message into the
output and continue booting the guest without hugepage support. Autotest
than runs all the test. Later in the output is no mention about this.
You have to predict that this happend and look at debug output of all
particular tests to see if qemu didn't produced this message.
Using this check if qemu-kvm can't allocate the hugepage memory it fails
this test, log this information and continue with next variant.
Dne 9.7.2009 14:30, Michael Goldish napsal(a):
I don't think you need to explicitly check for a memory allocation
failure in VM.create() ("qemu produced some output ...").
VM.create() already makes sure the VM is started successfully, and
prints informative failure messages if there's any problem.
----- "Lukáš Doktor"<ldok...@redhat.com> wrote:
This patch adds kvm_hugepage variant. It prepares the host system and
start vm with -mem-path option. It does not clean after itself,
because
it's impossible to unmount and free hugepages before all guests are
destroyed.
There is also added autotest.libhugetlbfs test.
I need to ask you what to do with change of qemu parameter. Newest
versions are using -mempath insted of -mem-path. This is impossible to
fix using current config file. I can see 2 solutions:
1) direct change in kvm_vm.py (parse output and try another param)
2) detect qemu capabilities outside and create additional layer
(better
for future occurrence)
I'll have to think about this a little before answering.
Tested by:ldok...@redhat.com on RHEL5.4 with kvm-83-72.el5
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
