Bug 523197

Created attachment 360942 [details]
# LIBVIRT_DEBUG=LEVEL virsh start rhel-i386-client-5-u4-XenPVGuest

my xen host is rhel54 x86_64 and guest was rhel54i386client paravirt:

redhat-release-5Server-5.4.0.3
libvirt-0.6.3-20.el5
libvirt-0.6.3-20.el5
xen-3.0.3-94.el5
kernel-2.6.18-164.el5
kernel-xen-2.6.18-164.el5

and it works:
# xm create psklenar-xenpvGuest-i386-5Client
Using config file "/etc/xen/psklenar-xenpvguest-i386-5Client".
Started domain psklenar-xenpvguest-i386-5Client

######> then I stopped that guest and:
# virsh start psklenar-xenpvguest-i386-5Client
Domain psklenar-xenpvguest-i386-5Client started

all works as expected, but host was rhel54 x86_64

I tried more machines and there is some issue with machine installed with package set = @Everything
virt-manager:

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: (2, 'Invalid kernel', 'xc_dom_parse_elf_kernel: ELF image has no shstrtab\\n')")

I installed 4 machine: three machine (@everything) don't work and one with @base works (Comment #3)

Ok, so i figured this out.

When you do an @Everything install it installs multiple (non-Xen) kernels.

I mounted the disk image and found the following kernel packages installed:

kernel-xen-2.6.18-164.el5
kernel-2.6.18-164.el5
kernel-PAE-2.6.18-164.el5


and grub was set to boot the PAE kernel which won't work for Xen PV!

So essentially you can't ever use @Everything with a Xen PV install, unless you can do something like:

@Everything
-kernel-PAE
-kernel

I'd have to test that though, much safer to do @Base.

I edited the disk image and changed grub to boot to the kernel-xen kernel, and it boots up fine on dhcp-lab-133.englab.brq.redhat.com

-Justin

So it turns out it's not a Xen bug. It might be a bug in another component but I'm not sure which one. That said, I'm closing this as NOTABUG. If you feel there is something to be fixed in another component, feel free to reopen it and set the component appropriately. Or even file a completely new bug with more appropriate description.

Hello,
I created ks i386-rhel54Client-paravirt-guest with following package set: 

@Everything
-kernel-PAE
-kernel

which works for me and right kernel-xen is booted

This is definitely not a kickstart tree issue, I also confirmed its the identical behavior on RHEL 5.3.  A simpler way to create this scenario is to do:

%packages --resolvedeps

kernel
kernel-PAE
kernel-debug
@ Base


in the kickstart file (so you don't have to wait for @ Everything.  So, even though we have cleared the 5.4 kickstart trees from being a problem, it does feel like this is either a Kernel or Anaconda bug.  I don't know if there is any way to create a proper conflicts for the paravirtualized guest case, so it might just be a situation where Anaconda shouldn't allow this to occur.  I'll leave it to the discretion of others, but I feel this is a valid bug to reopen and assign to kernel or anaconda.

(In reply to comment #8)
> This is definitely not a kickstart tree issue, I also confirmed its the
> identical behavior on RHEL 5.3.  A simpler way to create this scenario is to
> do:
> 
> %packages --resolvedeps
> 
> kernel
> kernel-PAE
> kernel-debug
> @ Base
> 
> 
> in the kickstart file (so you don't have to wait for @ Everything.  So, even
> though we have cleared the 5.4 kickstart trees from being a problem, it does
> feel like this is either a Kernel or Anaconda bug.  I don't know if there is
> any way to create a proper conflicts for the paravirtualized guest case, so it
> might just be a situation where Anaconda shouldn't allow this to occur.  I'll
> leave it to the discretion of others, but I feel this is a valid bug to reopen
> and assign to kernel or anaconda.  

It's definitely not a kernel bug.  You don't want to have kernel-PAE conflict with kernel-xen, for instance; you might want to do something funky where you are dual-booting the same domain both as an HVM guest and a PV guest.  And in the above scenario, you are deliberately shooting yourself in the foot.

So that just leaves the "Everything" install, which is the only real source of problem.  In that case, anaconda should still be choosing the kernel-xen as the default kernel, since it is a PV guest.  Therefore, the only reasonable place to ask for a bugfix would be anaconda.

Chris Lalancette

Please see comments #8 and #9 to see why I'm re-opening this.

You chose to do an everything install, which simply does just what its name says - installs everything.  That's all the packages, even though they may not make any sense.  If you want finer grained control over your installed package set, you can deselect things in the UI, remove them via kickstart as you have done, or simply not do an Everything install.

Problems like this are why we have stopped recommending these sorts of installs, and I do not want to add an ever-increasing and ever-out-of-date list of hacks to anaconda for what packages shouldn't be part of Everything and why.

(In reply to comment #11)
> You chose to do an everything install, which simply does just what its name
> says - installs everything.  That's all the packages, even though they may not
> make any sense.  If you want finer grained control over your installed package
> set, you can deselect things in the UI, remove them via kickstart as you have
> done, or simply not do an Everything install.
> 
> Problems like this are why we have stopped recommending these sorts of
> installs, and I do not want to add an ever-increasing and ever-out-of-date list
> of hacks to anaconda for what packages shouldn't be part of Everything and why.  

But that's not what this is about.  Selecting "Everything", and having anaconda install everything under the sun is just fine.  The problem is that anaconda chose the wrong kernel as the default kernel at the end of the install.  Anaconda knows that it is running as a Xen guest, and in the normal circumstance, it does the right thing and installs the kernel-xen package and sets it as the default.  For some reason in the Everything install, it installs the kernel-xen package, but does not set it as default, which is the problem.

Chris Lalancette

P.S.  I have not verified the problem myself, but this is going off of the problem described in Comment #8 and #9.

Yep, exactly. Which component is choosing correct default kernel?