Hi Laszlo and Rich,
Thanks for the quick and detailed explanation! kexec-tools is
responsible for setting the kernel command line parameter crashkernel.
And when there is an update of the default crashkernel value, it will
try to reset crashkernel to the new default value during package update.
A customer could use virt-customize to update kexec-tools and this is
how virt-customize enters the picture.
Pingfan has decided to drop getconf in next version since RHEL9 arm use
4k page size. So there will not be a problem for running virt-customize
to update kexec-tools.
Note I've also left some inline comments.
On Wed, Jun 08, 2022 at 06:09:01PM +0100, Richard W.M. Jones wrote:
On Wed, Jun 08, 2022 at 04:34:47PM +0200, Laszlo Ersek wrote:
> +Rich
>
> On 06/08/22 11:49, Coiby Xu wrote:
> > Hi Laszlo,
> >
> > We meet a problem that when running "getconf PAGESIZE" with
> > virt-customize, the returned value is not the page size of the guest
> > image and it's likely the value of the VM started by virt-customize.
> > Since you the expert on virt-customize, do you know what's the
> > recommended way to get the page size of a guest image and how do we tell
> > if we are inside a virt-customize environment? If there is no good way,
> > how likely is rhel8 virt-customize used to modify rhel9 cloud images? If
> > this is not likely to happen, we may simply ignore this case.
>
> I don't understand (after skimming the below too) how virt-customize
> enters the picture here. "page size" is not really a guest filesystem
> dependent concept, but a guest *kernel* dependent concept. And
> libguestfs (and the dependent virt tools, such as virt-customize) use a
> separate kernel, initrd, and small root filesystem (which we together
> call "appliance") for manipulating guest disk images. The appliance is
> usually collected from host-side packages; so by default you get the
> host-side kernel in the appliance when you fire up virt-customize. That
> kernel may use a different page size from any kernel that might be
> installed on the guest disk.
Thanks for giving me a big picture of how virt-customize works!
>
> libguestfs-based tools do attempt to query some information out of the
> guest-installed kernels, for example virt-v2v looks at various CONFIG
> options to see if various virtio devices are supported by the installed
> guest kernel(s). The page size is not something that we look at (to my
> knowledgge) -- why do you care about guest pagesize, and why do you
> think that libguestfs and/or virt-customize is a good way to determine
> it? What is your end goal?
>
> Libguestfs documentation about running commands in general:
>
>
https://libguestfs.org/guestfs.3.html#running-commands
Thanks for the documentation!
This isn't something that virt-customize can really handle. It boots
an appliance using the host kernel and so getconf PAGESIZE running in
that appliance (say, in an RPM %post script) is going to return the
host kernel page size. Getting the page size from the guest kernel
when it isn't running is painful. You could in theory look into
/boot/config*, but it might not be present, or might not correspond to
the kernel which is finally installed.
I couldn't find where exactly you're calling getconf. It doesn't seem
to be present in the Rawhide RPM:
https://src.fedoraproject.org/rpms/kexec-tools/tree/rawhide
This patch hasn't been merged due to this concern about getconf. With
this patch, getconf is supposed to be called in this way: kexec-tools
package update -> RPM scriptlet -> kdumpctl get-default-crashkernel ->
getconf.
In general though, there are lots of ways that RPMs are installed
which don't use the final kernel during installation, so you're going
to hit this problem in many contexts -- eg in containers or clouds
where it's very common to build an image which is used as a template
for many deployments.
Yes, take osbuild as an example, osbuild exposes the
container=bwrap-osbuild environment variable to tell if we inside the
its container. I'm curious if guest-customize has provided a similar way
in case we need to treat guest-customize specially in the future.
Probably best to do the test at runtime right before you need it.
Thanks for the suggestion! As said before, Pingfan plans to drop getconf
in next version.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
Best regards,
Coiby