virt March 2010

virt@lists.centos.org

30 participants
22 discussions

Fedora 12 2.6.31.5-127.fc12 domU on CentOS 5.4 2.6.18-164.6.1.el5xen fails to boot
by Charles J Gruener 06 Mar '10

06 Mar '10

Doing a kickstart install of Fedora 12 results in a non-bootable image. >From a virt-maanger instance, the error produced when trying to run the domU is: Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/engine.py", line 498, in run_domain vm.startup() File "/usr/share/virt-manager/virtManager/domain.py", line 573, in startup self.vm.create() File "/usr/lib64/python2.4/site-packages/libvirt.py", line 287, in create if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) libvirtError: POST operation failed: xend_post: error from xen daemon: (xend.err "Error creating domain: Boot loader didn't return any data!") If you drop to the command line to see what pygrub gets back, you get: # pygrub /var/lib/xen/images/fedora12.img Traceback (most recent call last): File "/usr/bin/pygrub", line 677, in ? fs = fsimage.open(file, get_fs_offset(file)) IOError: [Errno 95] Operation not supported The kickstart worked perfectly in Fedora 11 on a CentOS 5.4 dom0. I've tried investigating all sorts of grub options and even tried copying kernel and initramfs files out from the domU to dom0 and booting from those with no luck. The only thing that does work is if I install Fedora 11 and then perform an upgrade to Fedora 12. I really don't want to have to deploy machines this way. Is anyone else experiencing this issue? I can provide any further information requested. Basically, to repeat my error, install CentOS 5.4 with Virtualization, then try to install a Fedora 12 domU. The installation finishes without error but you can't boot. The systems are all x86_64. Thanks. Charles

9 31

Re: [CentOS-virt] [CentOS] Very unresponsive, sometimes stalling domU (5.4, x86_64)
by Pasi Kärkkäinen 02 Mar '10

02 Mar '10

On Tue, Mar 02, 2010 at 09:30:50AM +0100, Timo Schoeler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi list, > > please forgive cross posting, but I cannot specify the problem enough to > say whether list it fits perfectly, so I'll ask on both. > > I have some machines based with following specs (see at the end of the > email). > > They run CentOS 5.4 x86_64 with the latest patches applied, Xen-enabled > and should host one or more domUs. I put the domUs' storage on LVM, as I > learnt ages ago (what never caused any problems) and is way faster than > using file-based 'images'. > > However, there's something special about these machines: They have the > new WD EARS series drives, which use 4K sector sizes. So, I booted a > rescue system and used fdisk to start at sector 64 instead of 63 (long > story made short: Due to overhead causing the drive to do much more, > inefficient writes when starting at sector 63, the performance > collapses; with 'normal' geometry (sector 63), the drive achieves about > 25MiByte/sec writes, with starting at sector 64 partition, it achieves > almost 100MiByte/sec writes): > > [root@server2 ~]# fdisk -ul /dev/sda > > Disk /dev/sda: 1000.2 GB, 1000204886016 bytes > 255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors > Units = sectors of 1 * 512 = 512 bytes > > Device Boot Start End Blocks Id System > /dev/sda1 * 64 2097223 1048580 fd Linux raid > autodetect > Partition 1 does not end on cylinder boundary. > /dev/sda2 2097224 18876487 8389632 82 Linux swap / Solaris > /dev/sda3 18876488 1953525167 967324340 fd Linux raid > autodetect > > On top of those (two per machine) WD EARS HDs there's ``md'' providing > two RAID1, /boot and LVM, as well as swap per HD (i.e. non-RAIDed). LVM > provides the / partition as well as LVs for Xen domUs. > > I have about 60 machines running that style and never had any problems. > They run like a charm. On these machines, however, domUs are *very* > slow, have a steady (!) load of about two -- 50% stating in 'wait' -- > and all operations take ages, e.g. a ``yum update'' with the recently > released updates. > > Now, can that be due to 4K issues I didn't see, nestet now in LVM? > > Help is very appreciated. > Maybe the default LVM alignment is wrong for these drives.. did you check/verify that? See: http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-eras… Especially the "--metadatasize" option. -- Pasi

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

virt March 2010