[ANNOUNCE] kvm-kmod-2.6.32.2

[ANNOUNCE] kvm-kmod-2.6.32.2

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]

Before continuing to pimp up the tree, let's quickly update kvm-kmod:

This release follows latest KVM updates in stable 2.6.32 and also
includes the requested kvm kernel header installation. The latter is
specifically targeting at QEMU as, in contrast to KVM's QEMU tree,
upstream does not carry the latest kernel headers. QEMU should now be
able to pick them up via 'pkg-config kvm-kmod --cflags'.

Find this new version at:

https://sourceforge.net/projects/kvm/files/kvm-kmod/2.6.32.2/kvm-kmod-2.6.32.2.tar.bz2/download

KVM changes since kvm-kmod-2.6.32:
 - x86 emulator: limit instructions to 15 bytes
   (to limit latencies on non-preempt hosts)
 - Fix irq_source_id size verification
   (fixes guest hang with exhausted IRQ sources
 - Include pvclock MSRs in msrs_to_save

kvm-kmod changes since kvm-kmod-2.6.32:
 - Install kernel headers and related pkg-config metadata
 - Fix installation against non-current kernel
 - Fix cleanup-on-error of kvm-kmod compat services

Merry Christmas,
Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [ANNOUNCE] kvm-kmod-2.6.32.2

[Daniel Bareiro]

[-- Attachment #1: Type: text/plain, Size: 2902 bytes --]

Hi, Jan.

On Thursday, 24 December 2009 12:48:00 +0100,
Jan Kiszka wrote:

> Before continuing to pimp up the tree, let's quickly update kvm-kmod:
> 
> This release follows latest KVM updates in stable 2.6.32 and also
> includes the requested kvm kernel header installation. The latter is
> specifically targeting at QEMU as, in contrast to KVM's QEMU tree,
> upstream does not carry the latest kernel headers. QEMU should now be
> able to pick them up via 'pkg-config kvm-kmod --cflags'.
> 
> Find this new version at:
> 
> https://sourceforge.net/projects/kvm/files/kvm-kmod/2.6.32.2/kvm-kmod-2.6.32.2.tar.bz2/download
> 
> KVM changes since kvm-kmod-2.6.32:
>  - x86 emulator: limit instructions to 15 bytes
>    (to limit latencies on non-preempt hosts)
>  - Fix irq_source_id size verification
>    (fixes guest hang with exhausted IRQ sources
>  - Include pvclock MSRs in msrs_to_save
> 
> kvm-kmod changes since kvm-kmod-2.6.32:
>  - Install kernel headers and related pkg-config metadata
>  - Fix installation against non-current kernel
>  - Fix cleanup-on-error of kvm-kmod compat services

Thanks for the new version!

I have some doubts that I would like to consult:

Can this version of kvm-kmod be used with any version of Linux kernel?

I have Linux 2.6.32 in a host, but I suppose that considering, by the
date of publication of kvm-kmod, that the provided modules by this
package are newer and fix several bugs of the provided modules by Linux
2.6.32.

Also I have another host with Linux 2.6.30 and KVM-88, both compiled by
myself in that order. Then I didn't know that the userspace and the
kernel modules could be updated in independent form with qemu-kvm and
kvm-kmod, respectively; so I suppose that when installing KVM-88 in
second instance, it will have overwritten the newest modules of Linux
2.6.30. Is it correct? In this case, can have some problem installing
kvm-kmod 2.6.32.2 with Linux 2.6.30?

Today I had a problem with one of the VMs running under this environment
of kvm-88 + Linux 2.6.30 (with modules of kvm-88, if what I said before
is correct). This is a VM that runs a Java application server with high
rate of I/O.

The server didn't respond reason according to it showed Nagios. When I
acceded to host through the shell, it drew attention to me to see that
uptime reflected about 14697 days! When trying to execute "top", the
console was hung and I did not have another alternative that to do kill
-9 of the process. This could have due to some bug of that version of
KVM?

Perhaps it is an obvious question, but during the update process of the
modules, the virtual machines must be down?

> Merry Christmas,

Thanks. Merry Christmas also to all.

Regards,
Daniel
-- 
Fingerprint: BFB3 08D6 B4D1 31B2 72B9  29CE 6696 BF1B 14E6 1D37
Powered by Debian GNU/Linux Lenny - Linux user #188.598

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [ANNOUNCE] kvm-kmod-2.6.32.2

[Avi Kivity]

On 12/24/2009 09:10 PM, Daniel Bareiro wrote:
>
> Can this version of kvm-kmod be used with any version of Linux kernel?
>    

Not any version, but most.


> I have Linux 2.6.32 in a host, but I suppose that considering, by the
> date of publication of kvm-kmod, that the provided modules by this
> package are newer and fix several bugs of the provided modules by Linux
> 2.6.32.
>    

kvm-kmod-2.6.32.2 contains the kvm modules from Linux 2.6.32.2.  You're 
better off installing Linux 2.6.32.2 instead of kvm-kmod-2.6.32.2 on top 
of Linux 2.6.32 (since you get non-kvm fixes as well).

> Also I have another host with Linux 2.6.30 and KVM-88, both compiled by
> myself in that order. Then I didn't know that the userspace and the
> kernel modules could be updated in independent form with qemu-kvm and
> kvm-kmod, respectively; so I suppose that when installing KVM-88 in
> second instance, it will have overwritten the newest modules of Linux
> 2.6.30. Is it correct? In this case, can have some problem installing
> kvm-kmod 2.6.32.2 with Linux 2.6.30?
>    

It should work without problems.

> Today I had a problem with one of the VMs running under this environment
> of kvm-88 + Linux 2.6.30 (with modules of kvm-88, if what I said before
> is correct). This is a VM that runs a Java application server with high
> rate of I/O.
>
> The server didn't respond reason according to it showed Nagios. When I
> acceded to host through the shell, it drew attention to me to see that
> uptime reflected about 14697 days! When trying to execute "top", the
> console was hung and I did not have another alternative that to do kill
> -9 of the process. This could have due to some bug of that version of
> KVM?
>    

Looks like time drift.  You should upgrade to more recent versions and 
report.

> Perhaps it is an obvious question, but during the update process of the
> modules, the virtual machines must be down?
>

You cannot rmmod the kvm modules while virtual machines are running.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.