New Hardware VLI image

[jaawasth]

Hi Marcus,

Could you please help create a new SLES 15 SP1 for a new hardware we have with just the following parameters.

splash=verbose loglevel=3 nomodeset net.ifnames=1 console=tty0 console=ttyS0,115200 nmi_watchdog=0 disable_mtrr_trim earlyprintk=ttyS0,115200 quiet showopts

[jaawasth]

@schaefi , can you please provide the test image

[schaefi]

We should discuss this. I have just read your e-mail about new hardware and options. What you request are kernel options which are different for each of your new hardware components. I'm afraid but we can't create an entire new image just for managing a different set of kernel boot options. Doing so will make our image matrix to explode.

The structure images for Azure LI/VLI are created is based on the following:

LargeInstance | VeryLargeInstance
    => SLE-MAJOR(12|15)
        => SLE-SP(X)

If you now add another layer which is HW_VERSION this will be on top and would have a deep impact on the number of images. It will also impact your effort in testing all this.

kernel boot options must be set at the very beginning and we can't handle this in the yaml config file because at that point the image has already booted. You always have the opportunity to set boot options via the bootloader menu but I guess this is not a procedure you can work with on production.

If we include a HW_VERSION in our image build chain this also changes the name of the images because they will now contain an additional set of information. It would then no longer be for example SLES15-SP1-SAP-Azure-VLI-BYOS.x86_64-1.0.11-Devel-Build54.15.raw.xz but turns into something like SLES15-SP1-SAP-Azure-VLI-HW_XXX-BYOS.x86_64-1.0.11-Devel-Build54.15.raw.xz

and this will happen to all images. Furthermore we would then create a dependency to the hidden hardware of your data center. I'm very concerned about all this.

Usually new hardware makes old hardware to decommission. In this case we would update our images to match your new hardware constraints. But if we also have to keep other images for the hardware backward compatibility things will end up in a huge mess

I'm sorry I have no good solution for this in place

[schaefi]

I'm also concerned about the option settings:

• quiet: not a good idea, you want to see kernel messages
• crashkernel=232M,high crashkernel=80M,low: are you sure you want to delete this ?

[jaawasth]

@schaefi , sure we can remove quiet.

crashkernel=232M,high crashkernel=80M,low: are you sure you want to delete this ? this is part of kdump params, this will be required only when the customer is configuring kdump ? right now we are not able to do so, and can set it manully when we resolve the existing issues with kdump config on the new hardware.

Is it possible to release an image for a single instance this time, meanwhile we figure out how to handle the new hardwares ?

[rjschwei]

Unfortunately the conversation was forked. I just made some comments on the e-mail thread. We really need to understand which kernel parameters are in conflict and then look at those in detail. Otherwise everything that is needed should be able to co-exist.

@jaawasth can you please send a hardware profile (hwinfo command) for all generations of hardware that are currently deployed and for the systems you are trying to onboard. Please send via e-mail.

Thanks

[jaawasth]

@rjschwei , sorry i missed out this, I'll send across hwinfo for all our existing hardwares [over mail], just fyi, I have already asked the hw vendors to explore more on this front.