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:
XEN_KERNEL_MBARGS="--mbargs=dom0_mem=1024M,max:1024M loglvl=all guest_loglvl=all"
to
XEN_KERNEL_MBARGS="--mbargs=dom0_mem=1024M,max:1024M loglvl=all guest_loglvl=all com1=115200,8n1 console=com1"
(both of those should be one line if they wrap)
This is also where you can assign more or less memory to the dom0. etc. This article has some other possible parameters for the xen.gz line:
http://www.informit.com/articles/article.aspx?p=1187966&seqNum=4
5. Make sure this is set as well in /etc/sysconfig/xen-kernel:
BOOT_XEN_AS_DEFAULT="yes"
6. issue this command to upgrade the kernel:
yum --disablerepo=Xen4CentOS upgrade kernel-*
7. This should upgrade your kernel and it should also automatically update your /boot/grub/grub.conf to boot for dom0 use.
If, for some reason, you want to manually upgrade the grub.conf file yourself, set the BOOT_XEN_AS_DEFAULT to "no" instead of yes.
8. If you want to install the xen kernel in other places other than xen dom0 machines, just make sure not to install the xen package, and grub.conf will get standard and not xen kernel boot entries.
====================
Once ypu have done your updates, please delete /etc/yum.repos.d/xen-c6-RC1.repo
===================
Please report positive and negative experiences here so we can move this into the CentOS-6 xen4 repository (or fix things that are broken).
Thanks, Johnny HUghes
On Fri, Oct 10, 2014 at 2:41 AM, Johnny Hughes johnny@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:
- download the test repo file:
http://dev.centos.org/centos/6/xen-c6-RC1/xen-c6-RC1.repo
Put it in /etc/yum.repos.d/
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)
- 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?
-George
On 10/16/2014 11:25 AM, George Dunlap wrote:
On Fri, Oct 10, 2014 at 2:41 AM, Johnny Hughes johnny@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:
- download the test repo file:
http://dev.centos.org/centos/6/xen-c6-RC1/xen-c6-RC1.repo
Put it in /etc/yum.repos.d/
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)
- 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.
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.
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.
On Thu, Oct 16, 2014 at 5:52 PM, Johnny Hughes johnny@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@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:
- download the test repo file:
http://dev.centos.org/centos/6/xen-c6-RC1/xen-c6-RC1.repo
Put it in /etc/yum.repos.d/
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)
- 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
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@umich.edu wrote:
On Thu, Oct 16, 2014 at 5:52 PM, Johnny Hughes johnny@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@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:
- download the test repo file:
http://dev.centos.org/centos/6/xen-c6-RC1/xen-c6-RC1.repo
Put it in /etc/yum.repos.d/
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)
- 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
On 10/22/2014 05:52 AM, George Dunlap wrote:
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?
This would be difficult as it would happen on upgrades of xen too (the old version if xen is removed) .. so we will have to educate people on this instead.
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.
Yes, you can run it manually if you have all the things in place (it looks for:
1. /boot/xen.gz 2. /etc/sysconfig/xen-kernel 3. The proper variable in /etc/sysconfig/xen-kernel (BOOT_XEN_AS_DEFAULT="yes") set to yes.
So if you meet all of those conditions, it will update the kernel in grub automatically.
<snip>
Thanks, Johnny Hughes
CentOS – "Roll Your Own Xen"
On Oct 22, 2014, at 5:52 AM, George Dunlap dunlapg@umich.edu wrote:
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.
-
Brad Tarver -
George Dunlap -
Johnny Hughes