Tracking KVM development

Tracking KVM development

[Thomas Løcke]

Hey all,

I've recently started testing KVM as a possible virtualization
solution for a bunch of servers, and so far things are going pretty
well. My OS of choice is Slackware, and I usually just go with
whatever kernel Slackware comes with.

But with KVM I feel I might need to pay a bit more attention to that
part of Slackware, as it appears to a be a project in rapid
development, so my questions concern how best to track and keep KVM
up-to-date?

Currently I upgrade to the latest stable kernel almost as soon as its
been released by Linus, and I track qemu-kvm using this Git
repository:  git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git

But should I perhaps also track the KVM modules, and if so, from where?

Any and all suggestions to keeping a healthy and stable KVM setup
running is more than welcome.

:o)
/Thomas

Re: Tracking KVM development

[Avi Kivity]

On 03/21/2010 01:21 PM, Thomas Løcke wrote:
> Hey all,
>
> I've recently started testing KVM as a possible virtualization
> solution for a bunch of servers, and so far things are going pretty
> well. My OS of choice is Slackware, and I usually just go with
> whatever kernel Slackware comes with.
>
> But with KVM I feel I might need to pay a bit more attention to that
> part of Slackware, as it appears to a be a project in rapid
> development, so my questions concern how best to track and keep KVM
> up-to-date?
>
> Currently I upgrade to the latest stable kernel almost as soon as its
> been released by Linus, and I track qemu-kvm using this Git
> repository:  git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
>
> But should I perhaps also track the KVM modules, and if so, from where?
>
> Any and all suggestions to keeping a healthy and stable KVM setup
> running is more than welcome.
>
>    

Tracking git repositories and stable setups are mutually exclusive.  If 
you are interested in something stable I recommend staying with the 
distribution provided setup (and picking a distribution that has an 
emphasis on kvm).  If you want to track upstream, use qemu-kvm-0.12.x 
stable releases and kernel.org 2.6.x.y stable releases.  If you want to 
track git repositories, use qemu-kvm.git and kvm.git for the kernel and kvm.

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

Re: Tracking KVM development

[Thomas Løcke]

On Sun, Mar 21, 2010 at 1:23 PM, Avi Kivity <avi@redhat.com> wrote:
> Tracking git repositories and stable setups are mutually exclusive.  If you
> are interested in something stable I recommend staying with the distribution
> provided setup (and picking a distribution that has an emphasis on kvm).  If
> you want to track upstream, use qemu-kvm-0.12.x stable releases and
> kernel.org 2.6.x.y stable releases.  If you want to track git repositories,
> use qemu-kvm.git and kvm.git for the kernel and kvm.

Thanks Avi.

I will stay with the stable qemu-kvm releases and stable kernel.org
kernel releases from now on.

I've never heard of any KVM specific distributions. Are you aware of
any? My primary reason for going with Slackware, is because I already
know it. But if there are better choices for a KVM virtualization
host, then I'm willing to switch.

:o)
/Thomas

Re: Tracking KVM development

[Avi Kivity]

On 03/21/2010 06:37 PM, Thomas Løcke wrote:
> On Sun, Mar 21, 2010 at 1:23 PM, Avi Kivity<avi@redhat.com>  wrote:
>    
>> Tracking git repositories and stable setups are mutually exclusive.  If you
>> are interested in something stable I recommend staying with the distribution
>> provided setup (and picking a distribution that has an emphasis on kvm).  If
>> you want to track upstream, use qemu-kvm-0.12.x stable releases and
>> kernel.org 2.6.x.y stable releases.  If you want to track git repositories,
>> use qemu-kvm.git and kvm.git for the kernel and kvm.
>>      
> Thanks Avi.
>
> I will stay with the stable qemu-kvm releases and stable kernel.org
> kernel releases from now on.
>
> I've never heard of any KVM specific distributions. Are you aware of
> any? My primary reason for going with Slackware, is because I already
> know it. But if there are better choices for a KVM virtualization
> host, then I'm willing to switch.
>    

The only kvm-specific distribution I know of is RHEV-H, but that's 
probably not what you're looking for.  I'm talking about distributions 
that have an active kvm package maintainer, update the packages 
regularly, have bug trackers that someone looks into, etc.  At least 
Fedora and Ubuntu do this, perhaps openSuSE as well (though the latter 
has a stronger Xen emphasis).

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

Re: Tracking KVM development

[Alexander Graf]

On 21.03.2010, at 17:42, Avi Kivity wrote:

> On 03/21/2010 06:37 PM, Thomas Løcke wrote:
>> On Sun, Mar 21, 2010 at 1:23 PM, Avi Kivity<avi@redhat.com>  wrote:
>>   
>>> Tracking git repositories and stable setups are mutually exclusive.  If you
>>> are interested in something stable I recommend staying with the distribution
>>> provided setup (and picking a distribution that has an emphasis on kvm).  If
>>> you want to track upstream, use qemu-kvm-0.12.x stable releases and
>>> kernel.org 2.6.x.y stable releases.  If you want to track git repositories,
>>> use qemu-kvm.git and kvm.git for the kernel and kvm.
>>>     
>> Thanks Avi.
>> 
>> I will stay with the stable qemu-kvm releases and stable kernel.org
>> kernel releases from now on.
>> 
>> I've never heard of any KVM specific distributions. Are you aware of
>> any? My primary reason for going with Slackware, is because I already
>> know it. But if there are better choices for a KVM virtualization
>> host, then I'm willing to switch.
>>   
> 
> The only kvm-specific distribution I know of is RHEV-H, but that's probably not what you're looking for.  I'm talking about distributions that have an active kvm package maintainer, update the packages regularly, have bug trackers that someone looks into, etc.  At least Fedora and Ubuntu do this, perhaps openSuSE as well (though the latter has a stronger Xen emphasis).

Yes, we do. Though openSUSE 11.2 isn't exactly where I want it to be. Expect 11.3 to be a lot better there.

Alex

Re: Tracking KVM development

[Michael Tokarev]

Avi Kivity wrote:
[]
> The only kvm-specific distribution I know of is RHEV-H, but that's
> probably not what you're looking for.  I'm talking about distributions
> that have an active kvm package maintainer, update the packages
> regularly, have bug trackers that someone looks into, etc.  At least
> Fedora and Ubuntu do this, perhaps openSuSE as well (though the latter
> has a stronger Xen emphasis).

Debian is a lot better on this front than it used to be a year ago.
At least I'm trying to look for the bugreports on a regular basis ;)

/mjt

Re: Tracking KVM development

[Andre Przywara]

Thomas Løcke wrote:
> On Sun, Mar 21, 2010 at 1:23 PM, Avi Kivity <avi@redhat.com> wrote:
>> Tracking git repositories and stable setups are mutually exclusive.  If you
>> are interested in something stable I recommend staying with the distribution
>> provided setup (and picking a distribution that has an emphasis on kvm).  If
>> you want to track upstream, use qemu-kvm-0.12.x stable releases and
>> kernel.org 2.6.x.y stable releases.  If you want to track git repositories,
>> use qemu-kvm.git and kvm.git for the kernel and kvm.
> 
> Thanks Avi.
> 
> I will stay with the stable qemu-kvm releases and stable kernel.org
> kernel releases from now on.
> 
> I've never heard of any KVM specific distributions. Are you aware of
> any? My primary reason for going with Slackware, is because I already
> know it. But if there are better choices for a KVM virtualization
> host, then I'm willing to switch.
Please think twice about that. Every time I wanted to go away from 
Slackware because of missing packages I ended up with accepting the 
involved hassle with self-compiling because I could stay with the 
simplicity and clean design of Slackware.
I usually compile my own kernels anyway and use the Slackware kernels 
only for testing and installation. So I usually do "make oldconfig" on a 
stable 2.6.xx.>=3 kernel, and am happy with that. QEMU(-kvm) is not a 
problem at all, the dependencies are very small and with Slackware[64] 
13.0 it compiles out of the box with almost all features. I can send you 
a reasonably configured package (or build-script) if you like.
Currently both qemu-kvm-0.12.3 and Linux 2.6.33 work together very well, 
although I usually do only testing and development with KVM and actually 
"use" it very rarely. So if you need more upper level management tools 
(like libvirt) I cannot help you on this.

Regards,
Andre.

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 488-3567-12

Re: Tracking KVM development

[Thomas Løcke]

On Sun, Mar 21, 2010 at 9:19 PM, Andre Przywara <andre.przywara@amd.com> wrote:
> Please think twice about that. Every time I wanted to go away from Slackware
> because of missing packages I ended up with accepting the involved hassle
> with self-compiling because I could stay with the simplicity and clean
> design of Slackware.


Same here.


> I usually compile my own kernels anyway and use the Slackware kernels only
> for testing and installation. So I usually do "make oldconfig" on a stable
> 2.6.xx.>=3 kernel, and am happy with that. QEMU(-kvm) is not a problem at
> all, the dependencies are very small and with Slackware[64] 13.0 it compiles
> out of the box with almost all features. I can send you a reasonably
> configured package (or build-script) if you like.


I also use the config provided by Slackware as a foundation for newer
kernels, and I always compile my own.

I would very much like to see the build-script you mention.


> Currently both qemu-kvm-0.12.3 and Linux 2.6.33 work together very well,
> although I usually do only testing and development with KVM and actually
> "use" it very rarely. So if you need more upper level management tools (like
> libvirt) I cannot help you on this.


I've looked at libvirt a bit, and I fail at seeing the attraction. I
think I will stay with plain qemu-kvm, unless there are some very
compelling reasons for going down the libvirt route.

:o)
/Thomas

Re: Tracking KVM development

[Asdo]

> I've looked at libvirt a bit, and I fail at seeing the attraction. I
> think I will stay with plain qemu-kvm, unless there are some very
> compelling reasons for going down the libvirt route.
>   

Virsh (uses libvirt) is almost irreplaceable for us...
How do you start and stop virtual machines easily, get a list of the 
running ones... How do you ensure a virtual machine is never started 
twice? (would obviously have disastrous results on the filesystem) How 
do you connect on-demand to the graphics of the VM from your laptop, 
with a good security so that only the system administrator can do that? 
(virt-viewer provides very easy support for this, tunnelling VNC 
graphics over SSH, you connect by specifying the name of the host and 
the name of the VM... just great!)

If there is another way I'm interested, in fact libvirt also brings 
problems to us mainly because it takes a while to support latest KVM 
features, and also installing libvirt from source and configuring it 
properly for the host first time is much more difficult than for KVM 
sources.

Thank you

Re: Tracking KVM development

[Kenni Lund]

2010/3/22 Asdo <asdo@shiftmail.org>:
>
>> I've looked at libvirt a bit, and I fail at seeing the attraction. I
>> think I will stay with plain qemu-kvm, unless there are some very
>> compelling reasons for going down the libvirt route.
>>
>
> Virsh (uses libvirt) is almost irreplaceable for us...
> How do you start and stop virtual machines easily, get a list of the running
> ones... How do you ensure a virtual machine is never started twice? (would
> obviously have disastrous results on the filesystem) How do you connect
> on-demand to the graphics of the VM from your laptop, with a good security
> so that only the system administrator can do that? (virt-viewer provides
> very easy support for this, tunnelling VNC graphics over SSH, you connect by
> specifying the name of the host and the name of the VM... just great!)

I fully agree...I started out by starting the VMs by entering the
kvm-command directly in a terminal. Then I decided to put it in a
shell script, so I didn't have to type the same things over and over
again. Then I needed a way to easily start, stop and restart the
machines, so I wrote another script for this. Then I decided to extend
it with some more functionality, allowing me to list running machines
and ensure that machines weren't run more than once. Then I decided to
extended the script to parse *.conf files, which allowed me to
automatically configure VMs through one *.conf file per VM. Then I
hacked some more functionality into the script and ....

...now I've essentially hacked together some more or less ugly shell
script for handling my VMs. After spending a bit of time with Fedora
and libvirt/virsh, I feel quite stupid - this solves, if not all, then
most of my problems.

Right now I'm just waiting for RHEL/CentOS 6.0 to get released, so i
can get rid of my ugly shell script and make the switch to
libvirt/virsh for good :)

Best Regards
Kenni Lund

Re: Tracking KVM development

[Zdenek Kaspar]

Dne 21.3.2010 12:21, Thomas Løcke napsal(a):
> Any and all suggestions to keeping a healthy and stable KVM setup
> running is more than welcome.

Hi, I compile stable qemu-kvm releases from source and install under
/opt/qemu-kvm-${version}. With this setup I can run/test multiple
versions without messing up "any" distro..

HTH, Z.

Re: Tracking KVM development

[Tomasz Chmielewski]

> I've never heard of any KVM specific distributions. Are you aware of
> any?

Have you heard of Proxmox VE[1]?

It's built on top of Debian with virtualization in mind.


[1] http://pve.proxmox.com


-- 
Tomasz Chmielewski
http://wpkg.org