Hi Mihail,
On 10.04.2009, at 00:50, Mihail Panev wrote:
Hello,
I'm currently writing my bachelor's thesis on the KVM and ran a
series
of benchmarks, partly "home grown" on it. This was a few months ago. I
used the kvm package from the Debian sid repository (kvm-72) with
kernel
2.6.26, which at the time were both almost up-to-date :-) (upstream
KVM
was at 79 IIRC). Recently I found out that meanwhile KVM is at 84, and
has some exciting features like nested virtualization, which I would
like to test.
So I took the upstream KVM source from sf.net and compiled it myself.
All went OK, except that I wasn't able to find a KVM binary named
'kvm',
which was what it always used to be called, at least under Debian.
Also
no 'kvm-qemu', 'qemu' or the like.
The only thing even remotely close to what I need seems to be a
binary
called 'qemu-system-x86_64'. Except that I actually have a 32 bit
system! The CPU is 64-bit of course (see below), but I have a 32 bit
PAE
kernel with all 32 bit userland running on it.
So question #1: Is this the right thing to start, and if yes, what's
the story behind that name? I ran across some qemu-system-i386 on
google, but my compile did not produce such a binary.
Yes, the binary is called "qemu-system-x86_64". The story behind all
this is somewhere in the archive of this ML. This will probably go
away when qemu and kvm-userspace merge some day.
So even though that looked quite strange to me, I ran
'qemu-system-x86_64' instead of Debian's 'kvm'. That seemed to work,
except for two things:
First off, it crashed with an abort right on the first run, when I
started it with -m 2047M (this used to work OK with Debian's kvm-72).
Details see below, short description is:
*** glibc detected *** qemu-system-x86_64: corrupted double-linked
list
I experimented with different parameters to -m, and using a "binary
search" approach came to the conclusion that values up to 475M work
fine, from 476M upwards glibc aborts with that linked list error. In
particular, omitting -m altogether also works fine, since it
defaults to
128M IIRC.
I guess filing a bug on the kvm sourceforge bug tracker is the best
thing to do here.
So I booted my VM with -m 450M and it ran fine. However, no nested
virtualization seems to be supported. The guest's /proc/cpuinfo does
not
list the 'svm' flag, and installation of the 'kvm' package complains
about the CPU not supporting virtualization extensions. And yes, the
kvm-amd.ko module on the host was inserted with the explicit
parameters
"npt=1 nested=1" (though those should be the defaults anyway).
So question #2: Any hints to what I may be doing wrong?
You need to load the module with nested=1 (you did that) to enable
nested virtualization support in the kvm kernel module.
Now the second thing you need to do is pass -enable-nesting to qemu-
system-x86_64 in order to enable nesting support in the userspace part
too.
I agree that this is not exactly obvious, but I wanted to guard the
code as heavily as possible :-).
Also, keep in mind that for now only KVM in KVM works for me. Getting
for example Xen running should be definitely doable - it just didn't
work for me last time I tried. Speed is not exactly great yet either.
Please tell me how it works for you!
Thanks,
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
