[CentOS-virt] Test new xen, centos-release-xen and kernel for auto grub update on kernel install

[George Dunlap]

Hey Johnny!  I tested your most recent implementation of the
grub-update script, and it now seems to work whether I use the CentOS
xen packages or a self-built one.  Thanks for your work. :-)

One more thing though: it seems that the grub update is triggered on
the *kernel* install or upgrade; but not in the *xen* install or
remove.  So if someone installs both the CentOS Xen packages and the
dom0 kernel, and then for some reason removes the Xen packages without
removing the kernel, then the default grub entry will be pointing to a
non-existent xen binary; or, if you were to install the dom0 kernel
first, and then later install the xen packages, you wouldn't have an
entry for xen.  I'm not familiar with the rpm spec system, but would
it be possible to have the xen-hypervisor package kick the grub-update
script on install and remove?

Also, is it possible to run the grub-update script manually?  We could
then document that for users who want to roll their own Xen.

 -George

On Mon, Oct 20, 2014 at 11:09 AM, George Dunlap <dunlapg at umich.edu> wrote:
> On Thu, Oct 16, 2014 at 5:52 PM, Johnny Hughes <johnny at centos.org> wrote:
>> On 10/16/2014 11:25 AM, George Dunlap wrote:
>>> On Fri, Oct 10, 2014 at 2:41 AM, Johnny Hughes <johnny at centos.org> wrote:
>>>> The new process for auto updates of grub upon kernel install is in the
>>>> xen4centos testing repo.
>>>>
>>>> In order to test these as updates to an existing system, you can do this:
>>>>
>>>> 1. download the test repo file:
>>>>
>>>> http://dev.centos.org/centos/6/xen-c6-RC1/xen-c6-RC1.repo
>>>>
>>>> 2. Put it in /etc/yum.repos.d/
>>>>
>>>> 3. Issue this command:
>>>>
>>>> yum --disablerepo=Xen4CentOS upgrade xen\* centos-release-xen
>>>>
>>>> (that should install all the new files required to make the kernel
>>>> update work automatically)
>>>>
>>>> 4.  Review the new file /etc/sysconfig/xen-kernel ... if there is any
>>>> other items you want on the 'kernel /xen.gz' line, you would edit the
>>>> file.  For example, I like to add  'com1=115200,8n1 console=com1' to the
>>>> end of that line so I can use consoles in virsh.  So I would change the
>>>> line:
>>>
>>> Hmm -- so I take it that /etc/sysconfig/xen-kernel is now a part of
>>> the xen package...?
>>>
>>> One issue with this is that during normal Xen development I often make
>>> an RPM directly from the upstream repo, so while I have the xen4centos
>>> kernel & libvirt installed, I don't have a xen4centos xen installed.
>>>
>>> The nice thing about the current script in centos-release-xen is that
>>> it works with non-x4c xen packages.
>>>
>>> Sorry I hadn't thought about that side-effect when you mentioned this
>>> before. :-/
>>>
>>> Any thoughts?  Would it be possible to have the script in
>>> centos-release-xen and check for the existence of /boot/xen.gz, for
>>> instance?
>>
>> I don't think that is a good idea .. people might have the xen.repo
>> installed so that they can get the kernel.  But not xen installed (ie,
>> they are on a domU).  They want the kernel and have centos-release-xen
>> installed .. BUT they don't want the grub mods as they want to boot a
>> normal kernel.
>
> I'm a bit confused.  I suggested that the script only install xen if
> /boot/xen.gz exists.  If they don't have the hypervisor package
> installed, then /boot/xen.gz won't exist, and so it should fall back
> to the default behavior.  If they have the hypervisor package
> installed in the domU for some reason, then it will put /boot/xen.gz
> first unless they edit /etc/sysconfig/xen-kernel -- which is the same
> thing that would happen if they installed the hypervisor packages you
> have here, right?
>
> Hmm, maybe it wasn't clear that I was actually suggesting moving
> /etc/sysconfig/xen-kernel to centos-release-xen; I wasn't suggesting
> getting rid of it and just always loading the xen kernel if it exists.
>
>> The easier thing would be for you (as a one off installer situation) to
>> create your own /etc/sysconfig/xen-kernel manually if you want grub
>> updated.  It only has 2 variables.
>
> That's not too hard. :-)  But it does mean a bit of extra overhead for
> anyone installing a non-CentOS build of Xen (a local build, a snapshot
> of release candidate, &c).
>
> This solution was for C6 only, right -- C7 uses grub2, right?  If it
> was going to be something CentOS would be using going forward we might
> be able to make the argument for including it in the upstream Xen
> install.  But if it's just a patch to get C6 to work, I don't think
> upstream will be so keen.
>
>> I want to make it easy to get things right in the major use cases ..
>> which I think this solution does in the way it is split up.
>
> Right, so in your suggestion:
> - centos-release-xen installed, CentOS hypervisor installed:
> Automatically defaults to xen
> - centos-release-xen instlaled, CentOS hypervisor installed,
> xen-kernel edited: Whatever is configured
> - centos-release-xen installed, no hypervisor installed: Defaults to
> bare metal Linux
> - centos-release-xen installed, alternate Xen installed: Defaults to
> bare metal Linux (needs grub.conf editing every kernel update).
>
> Which means using the CentOS hypervisor packages are a little bit
> easier (since you don't need to remember to run grub-bootxen.sh on
> every kernel update); but it makes having an alternate Xen installed
> harder, because you need to actually edit menu.lst on every kernel
> update.
>
> In my suggestion (moving /etc/sysconfig/xen-kernel to
> centos-release-xen, checking to see if xen exists):
> - centos-release-xen installed, CentOS hypervisor installed:
> Automatically defaults to xen
> - centos-release-xen instlaled, CentOS hypervisor installed,
> xen-kernel edited: Whatever is configured
> - centos-release-xen installed, no hypervisor installed: Defaults to Linux
> - centos-release-xen installed, alternate Xen installed: Automatically
> defaults to Xen
> - centos-release-xen instlaled, alternate Xen installed, xen-kernel
> edited: Whatever is configured
>
> It seems to me my way keeps things just as sensible for when the
> CentOS hypervisor packages are installed, but makes things better in
> the case where an alternate Xen is installed (which is not uncommon,
> even for non-developers).
>
> Or am I missing something?
>
>  -George