xen-users
Re: [Xen-users] Xen 3.1 terrible slowly on a laptop
carlopmart wrote:
Nico Kadel-Garcia wrote:
carlopmart wrote:
Nico Kadel-Garcia wrote:
carlopmart wrote:
Nico Kadel-Garcia wrote:
carlopmart wrote:
Nico Kadel-Garcia wrote:
carlopmart wrote:
Hi all,
I have installed rhel 5.1 with xen 3.1 on a laptop and ALL is
terrible slowly (network, mouse, etc.) If I starts with a
normal kernel (without xen enabled) all works normally. Do I
need to pass any param to grub on xen enabled kernel to all
works ok??
Thanks ...
Laptops are always an adventure. Do you really have enough RAM?
RHEL 5 is a bit of a RAM pig. Are you using all the CPU's, or
only one? Is your hard drive an ATA drive that needs "hdparm"
used to set it optimally? Tell us more!
My laptop have 1 GB of RAM, and it is Pentium M 2.0Ghz. for
guests I only use one cpu. And another problem is clock: lost 5
minutes every 15 min.... runs so slowly on host ...
Umm. Not good. Are you running NTP on the Dom0, and being sure
not to run it on your DomU? And how much RAM did you allocatae
for DomU? RHEL 5 is really, really unhappy with less than 250
Meg, and not exactly thrilled with as little as 500 Meg.
Yes, I am running ntp on dom0 and not on domU. I am suing 384 MB
ram for guest, and rest for dom0.
OK. I wonder if you've got some other issues going on, such as the
CPU being throttled back to do power saving. But what does "free"
say in DomU about your available RAM? Are you swapping? And are you
using a file image, or an LVM partition? And when you built the
image, if you used a file image, did you make sure that it's not
"sparse"?
oops i think that you point me to the problem. I am using a sparse
file for guest disk ... Is this really a problem?? Can't i use
sparse files on a laptop??? And yes I have activated power saving ...
I've not played with it much, but using sparse files seems to be an
awful idea until you've actually populated the file system through
use. This means that your first system operations, such as installing
software, compiling new tools, or building new databases, are goiing
to suffer horribly from it.
I also can't help thinking that your Dom0 may not have its hard drive
set up correctly: if you're using an IDE or ATA drive, check what
"hdparm" says about it. You may get a huge performance benefit from a
"hdparm -d1c1 /dev/hda" or from setting up your sysconfig setttings
correctly for a contemporary ATA drive.
My guest config is:
kernel = "/boot/vmlinuz-2.6.9-67.ELxenU"
ramdisk = "/boot/initrd-2.6.9-67.ELxenU.img"
bootloader = "/usr/bin/pygrub"
WHOAH. Hold it right there. Why are you using those kernel and
ramdisk settings in company with the pygrub? You don't need them, and
you probably added them manually, rather than using virt-install, right?
Comment them out and just use the pygrub.
name = "RhelUpdates"
memory = "384"
maxmem = "384"
disk = [
'tap:aio:/data/xenvmguests/rhel4updates/rhel4vol01.xvda,xvda,w' ]
vif = [ 'type=ieomu, mac=00:16:31:a5:67:13, bridge=natxenbr0' ]
vcpus = 1
on_reboot = 'restart'
on_crash = 'destroy'
sdl = 0
vnc = 1
vfb = [ 'type=vnc,vncunused=1' ]
I think that hdparm returns correcty parameters:
/dev/hda:
multcount = 16 (on)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 16383/255/63, sectors = 156301488, start = 0
DMA it is activated, and this disk is IDE, I am not sure if I can
activate 32 bits transfer using -c1 option on hdparm.
Almost any hard drive made this millennium can use 32-bit: the IDE
defaults (more typically PATA now!) are set extremely, extremely low
performance for backwards compatible reasons, and really should be
updated. I once spent a long argument with a kernel developer about how
"the kernel picks the higher performance default!" and had to walk him
through the code that showed him, no, the kernel preserved what it was
set to the lat time it was warm-rebooted. It you actually power off, it
resets to to the lower settings and stays there until manually reset. It
led to a huge performance improvement and the cost savings of buying a
lot of big SCSI drives that had a serious kernel compatibility issue
(due to this developer's insistence on backporting everything from new
kernels instead of forward porting their modifications to a contemporary
kernel: b-r-r-r-r!
If I don't put which kernel image needs to startup on guest system
with kernel and ramdisk params, I can't start guest. Pygrub returns a
lot errors about doesn't find a valid kernel image.
Ahh. Do you have the matching kernel installed in your guest domain, so
that insmod can find them and install them? It definitely looks like
you've not successfully loaded the boot loader in a way that grub can
find it. Can you run "grub-install /dev/xvda1" from your working DomU
environment?
I will try to use a complete file image, and not sparse file ...
Cool. That's one source of performance issues to check.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Xen-users] Xen 3.1 terrible slowly on a laptop, carlopmart
- Re: [Xen-users] Xen 3.1 terrible slowly on a laptop, Nico Kadel-Garcia
- Re: [Xen-users] Xen 3.1 terrible slowly on a laptop, carlopmart
- Re: [Xen-users] Xen 3.1 terrible slowly on a laptop, Nico Kadel-Garcia
- Re: [Xen-users] Xen 3.1 terrible slowly on a laptop, carlopmart
- Re: [Xen-users] Xen 3.1 terrible slowly on a laptop, Nico Kadel-Garcia
- Re: [Xen-users] Xen 3.1 terrible slowly on a laptop, carlopmart
- Re: [Xen-users] Xen 3.1 terrible slowly on a laptop, Nico Kadel-Garcia
- Re: [Xen-users] Xen 3.1 terrible slowly on a laptop, carlopmart
- Re: [Xen-users] Xen 3.1 terrible slowly on a laptop,
Nico Kadel-Garcia <=
- Re: [Xen-users] Xen 3.1 terrible slowly on a laptop, carlopmart
- Re: [Xen-users] Xen 3.1 terrible slowly on a laptop, Nico Kadel-Garcia
- Re: [Xen-users] Xen 3.1 terrible slowly on a laptop, carlopmart
|
|
|