From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chegu Vinod Subject: Re: Large sized guest taking for ever to boot... Date: Fri, 08 Jun 2012 10:57:13 -0700 Message-ID: <4FD23CF9.5000203@hp.com> References: <1339173966.26976.95.camel@ul30vt> <4FD23221.5090208@hp.com> <1339177340.26976.111.camel@ul30vt> Reply-To: chegu_vinod@hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Alex Williamson Return-path: Received: from g6t0184.atlanta.hp.com ([15.193.32.61]:24165 "EHLO g6t0184.atlanta.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751394Ab2FHR5p (ORCPT ); Fri, 8 Jun 2012 13:57:45 -0400 In-Reply-To: <1339177340.26976.111.camel@ul30vt> Sender: kvm-owner@vger.kernel.org List-ID: On 6/8/2012 10:42 AM, Alex Williamson wrote: > On Fri, 2012-06-08 at 10:10 -0700, Chegu Vinod wrote: >> On 6/8/2012 9:46 AM, Alex Williamson wrote: >>> On Fri, 2012-06-08 at 16:29 +0000, Chegu Vinod wrote: >>>> Hello, >>>> >>>> I picked up a recent version of the qemu (1.0.92 with some fixes) and tried it >>>> on x86_64 server (with host and the guest running 3.4.1 kernel). >> BTW, I observe the same thing if i were to use 1.1.50 version of the >> qemu... not sure if this is really >> related to qemu... >> >>>> While trying to boot a large guest (80 vcpus + 512GB) I observed that the guest >>>> took for ever to boot up... ~1 hr or even more. [This wasn't the case when I >>>> was using RHEL 6.x related bits] >>> Was either case using device assignment? Device assignment will map and >>> pin each page of guest memory before startup, which can be a noticeable >>> pause on smallish (<16GB) guests. That should be linear scaling though >>> and if you're using qemu and not qemu-kvm, not related. Thanks, >> I don't have any device assignment at this point . Yes I am using qemu >> (not qemu-kvm)... > Just to be safe, are you using --enable-kvm with qemu? Yes... ----- /etc/qemu-ifup tap0 /usr/local/bin/qemu-system-x86_64 -enable-kvm \ -cpu Westmere,+rdtscp,+pdpe1gb,+dca,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pclmuldq,+pbe,+tm,+ht,+s s,+acpi,+ds,+vme \ -m 524288 -smp 80,sockets=80,cores=1,threads=1 \ -name vm1 \ -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/vm1.monitor,server,nowait \ -drive file=/dev/libvirt_lvm/vm.img,if=none,id=drive-virtio-disk0,format=raw,cache=none,aio=native \ -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 \ -monitor stdio \ -net nic,macaddr=52:54:00:71:01:01 \ -net tap,ifname=tap0,script=no,downscript=no \ -vnc :4 /etc/qemu-ifdown tap0 ---- >> The issue seems very basic... 'was earlier running RHEL6.3 RC1 on the >> host and the guest and the host and the guest seemed to boot fine.. > Note that RHEL is based on qemu-kvm. Thanks, Yep..knew that :) I was using upstream qemu-kvm and was encouraged to move away from it...to qemu. Vinod > > Alex >