Hi there,

    I am looking at using KVM for an embedded product. I am also new
to Virtualization so pardon if
I ask dumb questions. This is my first time posting to this forum.

   The embedded product that need to run KVM has:

         a. Intel processor with VT
         b. BIOS supports enabling VT
         c. Linux kernel 2.6.26 (from kernel.org)
         d. No VGA adapter
         e. Serial console
         f. BusyBox

  Need help to understand if KVM can be installed, configured and run
with c,d,e and f configuration
mentioned above?

  Also can I know
         a.  Is KVM code in Linux kernel 2.6.26 reliable?
         b.  Will latest KVM code from linux-kvm.org run on Linux kernel 2.6.26?
         c.  How can I find which version of KVM code is stable. Can I
find this using the version number
              of the KVM release?

    Thanks for any help on this.

Cheers
../Tom
--

[ message continues ]

It may be reliable or not, but it's certainly not supported.  If you 
have problems or questions you're unlikely to receive support (on kvm or 

You mean kvm-kmod?  It may, but I recommend at least 2.6.27 (when mmu 

It depends on your needs.  Many users are satisfied with the lastest 
stable branch (2.6.32.y or 2.6.34.y).  Others want a distribution for 
longer term support.  The adventuous run kvm.git master branch.


-- 
error compiling committee.c: too many arguments to function

--

[ message continues ]

Yes - the kernel part.  In fact there are no independent kvm releases 
any more, they're just ordinary kernel releases.

The userspace part - qemu-kvm - is released independently (and has its 

The latest version.  And I recommend 2.6.32.y or 2.6.34.y over 2.6.27.

-- 
error compiling committee.c: too many arguments to function

--

[ message continues ]

On Wed, Jun 23, 2010 at 7:33 AM, Avi Kivity <avi@redhat.com> wrote:


Does a certain version of qemu-kvm go hand in hand with a certain
version of KVM
code in the Linux kernel release?

Does the KVM community recommend or announce a version of qemu-kvm is
good to go after testing with a KVM code it releases?
--

[ message continues ]

No.  I generally test the latest qemu-kvm with the latest kvm.

-- 
error compiling committee.c: too many arguments to function

--

[ message continues ]

Why 2.6.26, specifically if you seem to have no customized bits?
Starting with a pre-historic kernel for a new project is hardly ever a

That kernel is 2 years old, last version is 1.5 years old, and kvm was
still quite young into mainline at that time. There is a good chance you

kvm-kmod builds down to 2.6.24, but it is likely only tested down to
2.6.27. And you will miss quite a few relevant performance optimization
due to limitations of 2.6.26.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--

[ message continues ]

[ please use reply-all when posting to mailing lists ]


The effort you may save by sticking with 2.6.26 can quickly be consumed
by troubles and limitations you may face with this old kernel. Better
make sure your local bits are clean and easily portable to recent
kernels version - or even push them upstream. And if you already have a
test suite for your specific scenarios, switching the target shouldn't


Testing of kvm-kmod is a bit less ambitious. This compat package is not
that broadly used compared to the KVM modules that ship with standard or
distribution kernels. There are tests performed against 2.6.27 and
2.6.32 hosts ATM, but anything else depends on community feedback.
Still, we didn't face much kvm-kmod-specific issues in the recent past,
specifically after its stabilization phases.

However, if you decide to upgrade your kernel anyway, I would suggest to
go with the included KVM support first, only pick kvm-kmod if there is a
good reason.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--

[ message continues ]

Thanks you for the suggestions and the link (a neat one).

Cheers
../Tom
--

[ message continues ]

Busybox is an interesting requirement in that context.  If
you are constrained with userland size and linking against
other than glibc, use of qemu could be interesting.  Can't
say I've built it other than linked against glibc and an
extensive list of runtime libraries.  Although I've never
tried to configure-down that dependency. 

-john

-- 
john.cooper@third-harmonic.com
--

[ message continues ]