Hi, Troy, Davin, others!

Thanks a lot for the comments! I took time to look at my setup and
after some investigation found that I was running without kvm
assistance, but with pure qemu, i.e. full virtualisation. Since I was
really not aware of this, I think I'd make a check list for people on
how to make sure you are really running kvm.

1. Turn on cpu virtualization feature in the BIOS. On my Dell 2950 it
was off by default. I had to reboot, go to BIOS, enable the feature.
Make sure you power cycle after BIOS save. Dell does this
automatically. You'll know if you don't have cpu virtualization
feature set if you can't load kvm-intel or kvm-amd modules and see in
the /var/log/messages: kernel: kvm: disabled by bios.

2. Use -accelerate --hvm flags in virt-install

3. when you launched virtual machies, make sure the process is
/usr/libexec/qemu-kvm and there is no -no-kvm option in the command
line.

4. If something went wrong during creation, you may not notice it,
since system always silently falls back to qemu emulation.

5. If you need to correct some options, edit xml file for the domain,
especially paying attention to the following tags:

  <domain type='kvm'>

  <os>
    <type arch='x86_64' machine='pc'>hvm</type>

  <devices>
    <emulator>/usr/libexec/qemu-kvm</emulator>


if you changed something in the xml file, run virsh define
<path_to_xml>, otherwise wont take the values.

Once I made sure I run kvm, it actually runs quite good. :)

Answering concrete questions:

My host is 2 Xeon 5430, total 8 cores, Dell 2950, guests are all SL5.4 as well.

I have also moved to raw image, as Devi sugegsted.

Devin, you note on time drift might probably be cured by
-no-kvm-pit-reinjection, as I understood browsing for bug pages...

cheers
Artem.

On Mon, Feb 22, 2010 at 4:05 PM, Troy Dawson <[log in to unmask]> wrote:
> Artem Trunov wrote:
>>
>> Dear experts,
>>
>> It may not be SL specific, but I am sure there are a lot of experts here.
>> Have you had a good experience with KVM in the latest SL5.4? Is it
>> production-worthy?
>>
>
> It works for me, quite well actually.
>
>
>> I have the following issues:
>>
>
> One thing you haven't mentioned is what OS you are running on KVM.
> Note that all of my answers deal with SL3-SL5 and Fedora based virtual
> machines.
> I am runing on SL 5.4 with the latest kernels and security updates, but no
> fastbugs updates.
>
>> 1. Boot is only possible from ide bus, and drives are named hda. It seems
>> this is a feature of KVM?
>
> By default, this appears to be the case.
> It hasn't been an issue with me.
>
>> 2. Virtual machine can not use more than 1 host core, even if 2 virtual
>> cpus are configured for it.
>
> All of mine are setup to have 2 cpu's and they appear to be using them.
> How many physical CPU's do you have?  And how many cores per CPU?
>
>> 3. some times virtual machines lock up and go into a cpu curning loop,
>> consuming 100% of a host core. The solution is to kill qemu process.
>
> I haven't run into this except for when it is expected, like my virtual
> machines are running prelink, or compiling something.  Then I expect them to
> use up a whole CPU or two.
>
>> 4. virt-manager crashes shortly after first start up and few operations.
>> Subsequent restart of virt-manager doesn't lead to more crashes..
>
> I haven't ever run into this.  Sorry.
>
>> 5. It's slow, presumably because of disk operations. I see some 5MB/s max
>> read/write. I run a qemu native image format, stored on gpfs.
>>
>
> Disk speeds are the slow point, particual when all my virtual machines want
> to access the disk at the same time.  But as long as they aren't all
> fighting for the disk they have been fine.
> I have no idea what my image format is.  I run mine as file images and build
> the file image in the virt-manager during the install.  So I'm running
> whatever the default is.
>
>> My host system has all latest kernels and patches.
>>
>> Thanks in advance,
>> Artem.
>
> I know I haven't answered too many questions, but hopefully it get's the
> conversation rolling along.
>
> Troy
>
> --
> __________________________________________________
> Troy Dawson  [log in to unmask]  (630)840-6468
> Fermilab  ComputingDivision/LSCS/CSI/USS Group
> __________________________________________________
>