Hide Forgot
Description of problem: Booting a rhel6 guest last forever, taking lots of cpu resources. Avi has debugged the problem and saw that a char in the vm memory was replaced by a different one (though that in storage it was ok) which prevented the system to continue booting (replaced the "Vmlinuz" into "/mlinuz" in the boot command). Version-Release number of selected component (if applicable): 2.6.32-195.el6.x86_64 qemu-kvm-0.12.1.2-2.184.el6.x86_64 How reproducible: happens always with this specific guest Steps to Reproduce: no clear repo on how to get to this state but once there seems to be consistent. Actual results: guest fails to boot and stuck in endless loop Expected results: Additional info:
/boot/grub/grub.conf on disk is truncated: # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/mapper/vg_dhcp151128-lv_root # initrd /initrd-[generic-]version.img #boot=/dev/vda default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title Red Hat Enterprise Linux (2.6.32-131.0.15.el6.x86_64) root (hd0,0) kernel /vmlinuz-2.6.32-131.0.15.el6.x86_64 ro root=/dev/mapper/vg_dhcp151128-lv_root rd_LVM_LV=vg_dhcp151128/lv_root rd_LVM_LV=vg_dhcp151128/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us crashkernel=auto rhgb quiet elevator=deadline processor.max_cstate=1 initrd / (note initrd ends in /). The rest of the contents are in the ext3 journal, which grub doesn't replay. Looks like after the last kernel install the guest rebooted without flushing its journals.
Guest /etc/fstab: # # /etc/fstab # Created by anaconda on Wed Aug 17 17:56:42 2011 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # /dev/mapper/vg_dhcp151128-lv_root / ext4 defaults 1 1 UUID=af1b9691-9f28-455a-b7ca-1eaa378382ec /boot ext4 defaults 1 2 /dev/mapper/vg_dhcp151128-lv_swap swap swap defaults 0 0 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0
RHEL 6.2 beta host, RHEL 6.1 guest.
Please detail the storage layout: ide/virtio, qcow2/raw, chained image or standalone image, etc.
Storage layout: virtio, qcow2 chained image on FC storage.
Can this get reproduced? Was the VM shut-downed gracefully?
happened once, 1 out of 500 vms based on same template - all treated the same way - not gracefully.
It happened to me quite a lot on phys hardware - before I learned to sync before rebooting. What do you mean "not gracefully"? Were the guests rebooted hard? Was the kernel or grub command line updated after the guests were provisioned from the template?
I'd also like to look at the template itself.
Guests weren't doing much before hard rebooted and grub command line wasn't updated after provisioning the guest from the templates. I'll provide the template itself as well.
The template's log it clear.