qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Slow linux (RH5.6) guest reboot?


From: Kenton Cabiness
Subject: Re: [Qemu-devel] Slow linux (RH5.6) guest reboot?
Date: Mon, 03 Oct 2011 15:12:49 -0500
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0

One thing I forgot to mention is that this same guest image has no problem when installed bare metal.

Kenton

On 10/3/2011 1:20 PM, Kenton Cabiness wrote:
In general, we have seen that during a reboot of a
running guest (by issuing a 'reboot' command in the
guest), the guest goes down normally, but when coming
back up, during the udev phase, it takes anywhere from
a few seconds to a few hours to complete that part of the
boot.  Then the guest seems to behave itself after that.
If the guest is powered off (virsh destroy guest), then
restarted (virsh create guest), then udev returns to a
speedy few seconds.  It seems that the longer the guest
is up, the longer it takes udev (the +2 hour udev window
was on a guest up for 6 days) during a guest reboot.
It's always fast after a destroy/create.

Does anyone have any idea what could be causing the slowness
in boot and the variability of the time spent in udev?  Any
suggestions on where we should look?

Thanks,
Kenton

Specifics:
===========
Host OS:
    - RHEL 6.1 x64: (2.6.32-131.6.1.el6.x86_64)
    - qemu-kvm: qemu-kvm-0.12.1.2-2.160.el6_1.2.x86_64.rpm
    - libvirt: libvirt-0.8.7-18.el6.x86_64.rpm

Guest OS:
    - RHEL 5.6: (2.6.18-238.19.1.el5)

VM details:
    - 1 VM/guest on the host
    - VM size is 32GB ram and 10 cores (host has
        36GB and 12 cores total)
        - virtual disk drive is a local file on a RAID 1 disk
        - cpu pinning set to force each virtual core to
        a unique core (hyperthreading is turned on)
        - virtio for storage and network devices
    - have 16 ethernet devices tied to 16 bridges
      mapped to 2 NICS on the host
    - Use of iPXE and SGA bios for VM.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]