virt July 2009

virt@lists.centos.org

28 participants
19 discussions

High CPU usage when running a CentOS guest in VirtualBox
by Sagi Bashari 16 Nov '09

16 Nov '09

Hi, I am running CentOS 5.3 32bit as a VirtualBox 3.0.0 guest running on Windows XP. The Windows host CPU usage is constantly at 50% although the CentOS guest is completely idle (i.e. 0.00 load average). I know this is a common problem related to the 1000Hz frequency that the CentOS kernel runs at. With previous versions of CentOS, I used the kernel-vm package [1] and it solved my problem. However, according to the README [2] this isn't necessary as of CentOS 5.3 and therefore these packages are not maintained anymore (the latest released kernel-vm is 2.6.18-92.1.22). >From what I understand, as of CentOS 5.3 it is possible to use the "divider=10 clocksource=acpi_pm" to reduce the frequency to 100Hz. I tried this setting, and it made no difference at all. I also tried to install the VirtualBox guest extensions, and still, the host CPU never goes below 50%. Is there any way to solve this issue without resorting to a custom kernel build? Thanks, Sagi [1] http://people.centos.org/tru/kernel-vm/ [2] http://people.centos.org/tru/kernel-vm/readme.txt

17 55

domU shutdown with cx88 crashes dom0
by Christian Schuermann 10 Oct '09

10 Oct '09

Hi, I've got a big problem with a cx88 DVB card. It is passed through to a CentOS 5.3 domU (dom0 is CentOS 5.3 as well), but when I shutdown the domU, this happens: cx88[0]: mpeg risc op code error cx88[0]: mpeg - dma channel status dump cx88[0]: cmds: initial risc: 0xffffffff cx88[0]: cmds: cdt base : 0xffffffff cx88[0]: cmds: cdt size : 0xffffffff cx88[0]: cmds: iq base : 0xffffffff cx88[0]: cmds: iq size : 0xffffffff cx88[0]: cmds: risc pc : 0xffffffff cx88[0]: cmds: iq wr ptr : 0xffffffff cx88[0]: cmds: iq rd ptr : 0xffffffff cx88[0]: cmds: cdt current : 0xffffffff cx88[0]: cmds: pci target : 0xffffffff cx88[0]: cmds: line / byte : 0xffffffff cx88[0]: risc0: 0xffffffff [ INVALID sol eol irq2 irq1 23 22 21 20 19 18 cnt1 cnt0 resync 14 13 12 count=4095 ] cx88[0]: risc1: 0xffffffff [ INVALID sol eol irq2 irq1 23 22 21 20 19 18 cnt1 cnt0 resync 14 13 12 count=4095 ] cx88[0]: risc2: 0xffffffff [ INVALID sol eol irq2 irq1 23 22 21 20 19 18 cnt1 cnt0 resync 14 13 12 count=4095 ] cx88[0]: risc3: 0xffffffff [ INVALID sol eol irq2 irq1 23 22 21 20 19 18 cnt1 cnt0 resync 14 13 12 count=4095 ] cx88[0]: iq 0: 0xffffffff [ INVALID sol eol irq2 irq1 23 22 21 20 19 18 cnt1 cnt0 resync 14 13 12 count=4095 ] cx88[0]: iq 1: 0xffffffff [ INVALID sol eol irq2 irq1 23 22 21 20 19 18 cnt1 cnt0 resync 14 13 12 count=4095 ] cx88[0]: iq 2: 0xffffffff [ INVALID sol eol irq2 irq1 23 22 21 20 19 18 cnt1 cnt0 resync 14 13 12 count=4095 ] cx88[0]: iq 3: 0xffffffff [ INVALID sol eol irq2 irq1 23 22 21 20 19 18 cnt1 cnt0 resync 14 13 12 count=4095 ] cx88[0]: iq 4: 0xffffffff [ INVALID sol eol irq2 irq1 23 22 21 20 19 18 cnt1 cnt0 resync 14 13 12 count=4095 ] cx88[0]: iq 5: 0xffffffff [ INVALID sol eol irq2 irq1 23 22 21 20 19 18 cnt1 cnt0 resync 14 13 12 count=4095 ] cx88[0]: iq 6: 0xffffffff [ INVALID sol eol irq2 irq1 23 22 21 20 19 18 cnt1 cnt0 resync 14 13 12 count=4095 ] cx88[0]: iq 7: 0xffffffff [ INVALID sol eol irq2 irq1 23 22 21 20 19 18 cnt1 cnt0 resync 14 13 12 count=4095 ] cx88[0]: iq 8: 0xffffffff [ INVALID sol eol irq2 irq1 23 22 21 20 19 18 cnt1 cnt0 resync 14 13 12 count=4095 ] cx88[0]: iq 9: 0xffffffff [ INVALID sol eol irq2 irq1 23 22 21 20 19 18 cnt1 cnt0 resync 14 13 12 count=4095 ] cx88[0]: iq a: 0xffffffff [ INVALID sol eol irq2 irq1 23 22 21 20 19 18 cnt1 cnt0 resync 14 13 12 count=4095 ] cx88[0]: iq b: 0xffffffff [ INVALID sol eol irq2 irq1 23 22 21 20 19 18 cnt1 cnt0 resync 14 13 12 count=4095 ] cx88[0]: iq c: 0xffffffff [ INVALID sol eol irq2 irq1 23 22 21 20 19 18 cnt1 cnt0 resync 14 13 12 count=4095 ] cx88[0]: iq d: 0xffffffff [ INVALID sol eol irq2 irq1 23 22 21 20 19 18 cnt1 cnt0 resync 14 13 12 count=4095 ] cx88[0]: iq e: 0xffffffff [ INVALID sol eol irq2 irq1 23 22 21 20 19 18 cnt1 cnt0 resync 14 13 12 count=4095 ] cx88[0]: iq f: 0xffffffff [ INVALID sol eol irq2 irq1 23 22 21 20 19 18 cnt1 cnt0 resync 14 13 12 count=4095 ] cx88[0]: fifo: 0x00186400 -> 0x187400 cx88[0]: ctrl: 0x001807c0 -> 0x180820 cx88[0]: ptr1_reg: 0xffffffff cx88[0]: ptr2_reg: 0xffffffff cx88[0]: cnt1_reg: 0xffffffff cx88[0]: cnt2_reg: 0xffffffff This loops forever eating every available cpu cycle. The dom0 becomes unusably slow until I manually destroy the domU. The domU runs 2.6.18-128.1.10.el5xen with video4linux-kmdl-2.6.18-128.1.10.el5xen-20090415-88.0.4.el5 (there are no video4linux-kmdls for the latest kernel yet). Manually unloading the modules before shutting down has no effect. Without video4linux-kmdl installed, everything works fine. I hope you can help me. Regards, Chris

1 2

Cluster failover
by Paras pradhan 01 Sep '09

01 Sep '09

hi, I have 3 nodes of CentOS 5.3 running xen virtual machines as virtual machine service. This cluster is working fine. One thing I would like to know that how to make failover only to third node. What I mean to say is: I have 3 virtual machine running on node 1 and 2 virtual machines running on node 2. Now if node 1 fails I want my the node1 virtual machines to be stared only on node 3 but not on node2. Similary if node2 breaks, I want virtual machines to be started on node3 but never on node 1. Thanks ! Paras.

2 1

Migrate windows VM from i386 Host to x86_64 host
by James Roman 01 Sep '09

01 Sep '09

Somehow one of our Xen servers ended up loaded with the i686 xen kernel, instead of the x86_64. The host has one windows VM running on it. The OS partition is file-based, but it also has a logical volume partition assigned for data. We would like to migrate the host server to a 64-bit kernel, which means moving the VM to one of our other 64-bit host servers. We tried simply copying the OS partition and using dd to move the LVM partition to a new host unsuccessfully. I'm pretty sure that dd may not be appropriate when moving between kernel architectures. However, even without the LVM partition specified in the vm config file, we are unable to boot the windows system. It looks like it is blue screening immediately, since we never get a console connection. Are there any instructions anywhere for moving VMs from one host architecture to another? Current Host: Centos 5.3 i686 kernel 2.6.18-128.2.1.el5 Xen 3.0.3-80.el5_3.3 Destination Host: Centos 5.3 x86_64 kernel 2.6.18-128.2.1.el5 Xen 3.0.3-80.el5_3.3

2 1

Can I bridge a bonded and vlan tagged interface directly to a guest?
by David Knierim 03 Aug '09

03 Aug '09

I am running CentOS 5.3 x86_64 as my dom0 and CentOS 5.3 on my domU's. On the dom0, I have two interfaces that are bonded and have tagged VLANs. I can get the networks to the domU's by creating a bridge for each of the VLANS (bond0.3, bond0.4, etc). On the domU, the interfaces show up as eth0, eth1, etc. Is there a way to set up the network on the dom0 so my domU's see a single interface with tagged VLAN support?? Thanks! David

3 4

Loading default keymap error after a yum update...
by Davide Perini 29 Jul '09

29 Jul '09

Hi, I'm running CentOS 5.3 on a XEN VPS. After I yum update, I've got this error on boot. Press 'I' to enter interactive startup. Cannot access the Hardware Clock via any known method. Use the --debug option to see the details of our search for an access method. Setting clock (utc): Thu Jul 16 18:54:50 CEST 2009 [ OK ] Starting udev: [ OK ] Loading default keymap (us): /etc/rc.d/rc.sysinit: line 396: /dev/tty0: No such file or directory [FAILED] Setting hostname localhost.localdomain: [ OK ] is there a solution to that problem? please help. thanks. Davide.

1 0

ntp on kvm
by Johnny Tan 28 Jul '09

28 Jul '09

We've noticed our fully-virtualized KVM guests' time keeps getting faster, despite running ntpd. A quick google reveals this to be a known problem with virtual guests. It seems there are a variety of solutions, some apparently vendor-specific. What is the best practice as of now for KVM guests? * Setting independent_wallclock=1 (or is that a xen-only thing)? * Passing kernel parameters? If so, which? The vmware KB mentions "notsc divider=10" -- is that vmware-specific? * Just don't run ntpd on virtual guests? And let it get its time from the host. The last seems like the easiest/cleanest, if it really does always get its time from the host. Thanks for any info. johnny

3 3

Installing/running Fedora 10 or Fedora 11 32b Xen domU on CentOS 5.3 x86_64 host/dom0 broken
by Pasi Kärkkäinen 28 Jul '09

28 Jul '09

Hello. Yesterday I tried installing Fedora 10 and Fedora 11 i386 Xen domUs/guests using virt-install and/or virt-manager on CentOS 5.3 Xen x86_64 dom0/host. It doesn't work. The guest kernel crashes early and the graphical VNC console newer shows up. Installing x86_64 domU on x86_64 dom0 work well. 32-on-32 works aswell. So it's a 32-on-64 bug. CentOS 5.3 32b guest on x86_64 host works though, most probably because it uses the "original" Xenlinux patchset. I found the upstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=467698 This problem will be fixed in upcoming RHEL 5.4, and it's also fixed in the latest el5 test kernel-xen (-159). I think this is not really F10 or F11 guest specific, but more likely will happen with any/many upstream (kernel.org) pv_ops Xen domU kernels. -- Pasi

1 0

I/O load distribution
by Dennis J. 27 Jul '09

27 Jul '09

Hi, What is the best way to deal with I/O load when running several VMs on a physical machine with local or remote storage? What I'm primarily worried about is the case when several VMs cause disk I/O at the same time. One example would be the "updatedb" cronjob of the mlocate package. If you have say 5 VMs running on a physical System with a local software raid-1 as storage and the all run updatedb at the same time that causes all of them to run really slowly because the starve each other fighting over the disk. What is the best way to soften the impact of such a situation? Does it make sense to use a hardware raid instead? How would the raid type affect the performance in this case? Would the fact that the I/O load gets distributed across multiple spindles in, say, a 4 disk hardware raid-5 have a big impact on this? I'm currently facing the problem where I fear that random disk I/O by too many VMs on a physical system could cripple their performance even though I have plenty of CPU cores/RAM left to run them. Has anyone experience with this problem and maybe some data to shed some light on this potential bottleneck for virtualization? Regards, Dennis

4 6

Re: [CentOS-virt] I/O load distribution
by Christopher G. Stach II 27 Jul '09

27 Jul '09

----- "Dennis J." <dennisml(a)conversis.de> wrote: > Hi, > What is the best way to deal with I/O load when running several VMs on > a > physical machine with local or remote storage? Fill up on controller cache, add more spindles until you saturate the bus, then start adding more controllers. > What I'm primarily worried about is the case when several VMs cause > disk > I/O at the same time. One example would be the "updatedb" cronjob of > the > mlocate package. If you have say 5 VMs running on a physical System > with a > local software raid-1 as storage and the all run updatedb at the same > time > that causes all of them to run really slowly because the starve each > other > fighting over the disk. Is this updatedb issue your only concern? Does it affect anything important? If it's just annoying, try to ignore it. Like any time sharing system, virtualization is a bet that things like this typically don't happen. > What is the best way to soften the impact of such a situation? Does it > make > sense to use a hardware raid instead? It won't matter that much to change from software to hardware. Arguably, the benefits of software RAID outweigh the negatives. It won't help you one bit in this case. A controller with a battery-backed cache will, though. > How would the raid type affect > the > performance in this case? Would the fact that the I/O load gets > distributed > across multiple spindles in, say, a 4 disk hardware raid-5 have a big > impact on this? It can affect it an awful lot. RAID 5 sucks. Avoid it. A little research will give you all of the reasons why. If you have a random access pattern like you'd typically see in a busy virtualized setup, RAID 10 is your best bet. If you're not heavy on writes, RAID 6 will save you some disk space... but disk is cheap enough to err on the side of unused performance if you don't want to spend the time to benchmark. Proper partitioning can give you back some performance in many cases, too. > I'm currently facing the problem where I fear that random disk I/O by > too > many VMs on a physical system could cripple their performance even > though I > have plenty of CPU cores/RAM left to run them. In most virtualized situations, I've seen it go down like this. In approximately this order, you will run out of... 1. RAM 2. disk I/O 3. CPU 4. network 3 and 4 will be swapped in a lot of cases. Regardless, this is the general order of priorities you should address while spec'ing your hardware or expect while setting your expectations with reappropriated hardware. If you have a two disk RAID 1 and 128GB of RAM and you run write-heavy databases (block device backing stores for anyone aiming to nitpick about OS filesystem cache) in all of the VMs, performance will not be that great. -- Christopher G. Stach II

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

virt July 2009