Also I wanted to point out that is there a particular reason for adding :

max:1024M

In CentOS 5 the max is not set by default. Many users who later want to increase the Dom-0 memory for VM creation or other reasons are unable to do so as the Max mem is set to 1024M.

Regards,

Pulkit Gupta

From: centos-virt-bounces@centos.org [mailto:centos-virt-bounces@centos.org] On Behalf Of PJ Welsh Sent: 03 October 2014 11:39 PM To: Discussion about the virtualization on CentOS Subject: Re: [CentOS-virt] Automate running grub-bootxen.sh for kernel installs in Xen4CentOS

Sounds consistent to existing precedence (like selinux).

Thanks!

PJ

On Fri, Oct 3, 2014 at 5:57 AM, Johnny Hughes johnny@centos.org wrote:

We need a way to do two things to /usr/bin/grub-bootxen.sh in Xen4CentOS.

1. Automate running it if xen (the package) and the xen kernel are installed. But only if the user WANTS to run it.

2. Allow users to automatically modify the variables passed into the xen.gz line (that is, more or less memory, add console settings, etc.) If you look at the current script, "--mbargs=dom0_mem=1024M,max:1024M loglvl=all guest_loglvl=all" is hard coded in as the only option for the xen.gz line.

While doing that we also still want to preserve the ability to run that kernel in other places than just for xen dom0 setups.

Here is how I propose we do that.

Currently the /usr/bin/grub-bootxen.sh file is in centos-release-xen ... that is a good place as it allows us to use a different file in different major versions of CentOS (so the file in 7 can be different than the file in 6, but still use the same auxiliary files, etc).

So, what we can do is setup a file in /etc/sysconfig/ (probably from the xen package) that we call xen-boot or xen-kernel, etc. In this file we put some variables like these:

BOOT_XEN_AS_DEFAULT="yes"

XEN_KERNEL_MBARGS="--mbargs=dom0_mem=1024M,max:1024M loglvl=all guest_loglvl=all"

Then we look for that file (/etc/sysconfig/xen-boot) as a post-install from the xen kernel. If the file exists, we source it ... an if BOOT_XEN_AS_DEFAULT is yes, and if /usr/bin/grub-bootxen.sh exists we run it passing in XEN_KERNEL_MBARGS as a variable.

The user can set BOOT_XEN_AS_DEFAULT to no if they want, so they do not get a xen kernel entry in their grub config.

That should mean that if either there is no '/etc/sysconfig/xen-boot' config file OR if '/usr/bin/grub-bootxen.sh' does not exist, we get only the standard kernel entry .. but if they do exist, we also get a user modifiable xen.gz kernel entry as well.

Also, we should likely use the centos-release-xen package to handle the '/etc/sysconfig/xen-boot' file as well, since it already has the /usr/bin/grub-bootxen.sh script.

Thoughts?

_______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt

On 10/09/2014 04:46 AM, George Dunlap wrote:

On Fri, Oct 3, 2014 at 11:57 AM, Johnny Hughes johnny@centos.org wrote:

...

We need a way to do two things to /usr/bin/grub-bootxen.sh in Xen4CentOS.

1. Automate running it if xen (the package) and the xen kernel are

installed. But only if the user WANTS to run it.

2. Allow users to automatically modify the variables passed into the

xen.gz line (that is, more or less memory, add console settings, etc.) If you look at the current script, "--mbargs=dom0_mem=1024M,max:1024M loglvl=all guest_loglvl=all" is hard coded in as the only option for the xen.gz line.

While doing that we also still want to preserve the ability to run that kernel in other places than just for xen dom0 setups.

Here is how I propose we do that.

Currently the /usr/bin/grub-bootxen.sh file is in centos-release-xen ... that is a good place as it allows us to use a different file in different major versions of CentOS (so the file in 7 can be different than the file in 6, but still use the same auxiliary files, etc).

So, what we can do is setup a file in /etc/sysconfig/ (probably from the xen package) that we call xen-boot or xen-kernel, etc. In this file we put some variables like these:

BOOT_XEN_AS_DEFAULT="yes"

XEN_KERNEL_MBARGS="--mbargs=dom0_mem=1024M,max:1024M loglvl=all guest_loglvl=all"

Then we look for that file (/etc/sysconfig/xen-boot) as a post-install from the xen kernel. If the file exists, we source it ... an if BOOT_XEN_AS_DEFAULT is yes, and if /usr/bin/grub-bootxen.sh exists we run it passing in XEN_KERNEL_MBARGS as a variable.

The user can set BOOT_XEN_AS_DEFAULT to no if they want, so they do not get a xen kernel entry in their grub config.

That should mean that if either there is no '/etc/sysconfig/xen-boot' config file OR if '/usr/bin/grub-bootxen.sh' does not exist, we get only the standard kernel entry .. but if they do exist, we also get a user modifiable xen.gz kernel entry as well.

Also, we should likely use the centos-release-xen package to handle the '/etc/sysconfig/xen-boot' file as well, since it already has the /usr/bin/grub-bootxen.sh script.

Thoughts?

This sounds reasonable to me.

One thing we also need to do is to make sure that when we *remove* xen, that these grub entries are removed as well.

Yep, got that working now as well (uninstall kernel takes away the xen entry or the normal entry, whichever is there).

My plan is to put the /etc/sysconfig/xen-kernel file in the xen package

And the /usr/bin/grub-bootxen.sh script (which switches the kernel to boot in dom0 mode) already lives in the centos-release-xen. (I need to modify this file to use the /etc/sysconfig/xen-kernel file for variables).

This would then mean that in order to automatically get a dom0 type kernel, you would need to install the centos-release-xen package AND the xen pacakge AND the kernel package. The only reason to do all 3 would be on a dom0 machine.

You can still have all 3 things installed and NOT get the dom0 boot settings in the grub.conf ... if you set BOOT_XEN_AS_DEFAULT="no" in /etc/sysconfig/xen-kernel.

You can also alter the mbargs setting in the /etc/sysconfig/xen-kernel by changing the XEN_KERNEL_MBARGS variable.

I have done the work for this and I am currently testing.

I will make the applicable packages available in the testing repo today or tomorrow and announce here for testing (depending on when it passes my tests, etc.).

Thanks, Johnny Hughes