On Fri, Nov 6, 2009 at 10:50 AM, James B. Byrne byrnejb@harte-lyne.ca wrote:

On Fri, November 6, 2009 13:30, James B. Byrne wrote:

...

When I choose the virtualization option during the first install of CentOS-5.4 do I get KVM or XEN?

Evidently, one gets XEN.  I will get kvm from extras and go about installing it manually.

You should have a choice at the installation time. Note that KVM is available for 64-bit only.

Akemi

On Fri, November 6, 2009 16:21, James B. Byrne wrote:

file /usr/share/man/man1/qemu-img.1.gz from install of qemu-0.9.0-4.x86_64 conflicts with file from package kvm-qemu-img-83-105.el5_4.9.x86_64

I infer from this that qemu is NOT required with KVM and that kvm-qemu takes its place.

Well, it turns out that qemu is required and kvm-qemu-img was the source of the problem. Removing this and installing qemu instead fixed the problem.

On Fri, 2009-11-06 at 16:21 -0500, James B. Byrne wrote:

On Fri, November 6, 2009 13:50, James B. Byrne wrote:

...

Evidently, one gets XEN. I will get kvm from extras and go about installing it manually.

# grep 'vmx' /proc/cpuinfo

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm

I installed kvm.x86_64-83-105.el5_4.9 successfully. I also installed virt-manager. I tried to install qemu but failed due to this file conflict:

Transaction Check Error: file /usr/share/man/man1/qemu-img.1.gz from install of qemu-0.9.0-4.x86_64 conflicts with file from package kvm-qemu-img-83-105.el5_4.9.x86_64

I infer from this that qemu is NOT required with KVM and that kvm-qemu takes its place.

Proceeding to the next stage I tried to load the kvm-module:

# modprobe kvm-intel

Which fails like this:

FATAL: Error inserting kvm_intel (/lib/modules/2.6.18-164.el5/weak-updates/kmod-kvm/kvm-intel.ko): Operation not supported

So, what is going on? What am I missing? The CentOS HowTos on kvm do not cover the current kernel insofar as I can see.

I checked the 'kvm' box during the install of 5.4 64bit and didn't have to install anything from the extras or rpmforge repos. It just worked right off the iso.

DaveM

David McGuffey wrote:

I tried VMWare's EXSi 4.0 on bare metal, and failed. Then I tried VirtualBox on CentOS 5.3 and failed.

What did these fail to do?

David McGuffey wrote:

On Sat, 2009-11-07 at 23:32 -0600, Les Mikesell wrote:

...

David McGuffey wrote:

...

I tried VMWare's EXSi 4.0 on bare metal, and failed. Then I tried VirtualBox on CentOS 5.3 and failed.

What did these fail to do?

Sorry it has taken so long to get back.

After screwing around for weeks trying to get a motherboard that at least was on the unofficial white list, I did get EXSi 4.0 to load. It was then that I realized I needed a separate Windoze workstation to load the vSphere to manage the VMs. I could only dedicate one machine to the virtualization testing.

If you set the VM's up with their own remote access (remote X, freenx, vnc, remote desktop, etc.) you only need the vSphere console to do the initial installs to the point where networking is up on the VM.

Then I tried VB on CentOS 5.3. For some reason, I couldn't get it to create a VM. So...

That doesn't make much sense.

I reloaded the machine with CentOS 5.4 (it had come out during my test), and selected 'kvm' during the install. That worked great.

At work, I loaded VB onto a Windoze XP Pro load and it locked up the machine. Corporate IT had to re-image it...along with a warning to me about mucking with their standard load.

It works OK on XP for me - but wouldn't that box have been a suitable place for the vSphere client?

Tonight, I just loaded VB onto Windoze XP 64. The load went OK, but when I created a VM for CentOS 5.4 (text mode), it hangs trying to bring up the network. That is the second failure I've had with VM.

There are several options for the network - are you using bridged or NAT? And does the console show it as connected?

Tomorrow I'm going to remove VB from the XP 64 load and install VMWare Server.

That should work too - although if you only plan to run one VM at a time and view its console locally you might as well use VMware player.

At this point in time, the only virtualization tool that loaded and 'just worked' has been kvm under CentOS 5.4. And...this is only a "Technology Preview" by Red Hat. For a TP, I'm impressed.

I don't think you can blame the other products for 'not working'.

On Sun, 2009-11-08 at 14:50 +0100, Mathieu Baudier wrote:

...

I've been doing a lot of research on virtualization (VMWare, EXSi, xen, kvm, VirtualBox, etc.) and ended up choosing kvm. I'm very surprised at how quick I was able to bring up a WinXP VM.

# FUTURE OF KVM David, I'm currently doing exactly the same (researching and comparing various virtualization technologies) and I agree that it seems the way to go in the future.

Only "problem" is that virt-manager is pretty hard to use and lacks a lot of features which would be practical. It is better though when using the one in Fedora, connecting to a CentOS box running libvirtd+KVM. What esp. lacks in the virt-manager distributed with CentOS 5.4 is the remote management of storage pools. I guess that the upstream vendor want to keep its proprietary Virtualization Server product attractive... (which is in itself a guarantee that they will keep investing in KVM, see: http://www.redhat.com/v/swf/rhev/demo.html)

# WIN XP UNDER QEMU+KVM Regarding running Windows XP, I just wanted to share the following with the list:

• when installing Windows XP through virt-manager, if one chooses

'Windows XP' as OS type and chooses more than 1 virtual CPU, some or all of the physical CPUs are used to 100% and the guest is very slow

• this seems to be due to a problem where ACPI is not properly

activated: https://bugs.launchpad.net/ubuntu/+source/virt-manager/+bug/228442

• the solution is to install it as 'Windows Vista': in that case this

is indeed extremely fast, and actually I do not have the pb described in the link above that it cannot shutdown.

I'm gathering experience around KVM and I'll probably try to contribute it to the CentOS Wiki when it is more consolidated.

I selected one virtual CPU for the XP load...primarily because I want to run a couple more VMs and the guidance was to allocate one real CPU per VM.

So far, I'm very impressed with kvm. However, I'm getting an SELinux alert on qemu, and have posted the sealert txt to the selinux-list for resolution. The VM seems to run ok, but I must do so as root, and not a regular user. kvm+qemu on CentOS is supposed to be able to be run as a regular user. The SELinux alert seems to revolve around the admin type (or lack thereof). I'm hoping the SELinux gurus can work it out.

In the meantime, I need to figure out how to get the XP VM to access a usb thumbdrive.

DaveM

On Mon, 2009-11-09 at 10:18 +0100, Mathieu Baudier wrote:

...

I selected one virtual CPU for the XP load...primarily because I want to run a couple more VMs and the guidance was to allocate one real CPU per VM.

My understanding is that Win XP will perform a fundamentally different install depending on whether it detects 1 or many CPU. So if you ever plan to reuse your VM with many CPUs, you should install it with many right away (and follow the tip above: install as Windows Vista, not XP).

I had this problem with a Win XP VM that I installed with pre v3.0 versions of VirtualBox: after VBox introduced SMP I could not use the multi-processor feature since XP had been installed with one processor.

Anyhow, now that I'm using KVM, for my test desktop VMs I tend to allocate a total of CPUs across the VMs higher than the number of my physical CPUs, since they rarely need CPU power at the same time but I want them to be able to run very smoothly if needed.

...

run a couple more VMs and the guidance was to allocate one real CPU per

Which guidance are you talking about?

In the Red Hat 5 Virtualization documentation it seems to strongly recommends having at least one physical cpu per VM. Since I have a quad core and I want to run the host plus 2-3 VMs, I decided give each VM one virtual cpu. Maybe I was too cautious.

Dave