Hi All, First, my apologies for the rather delayed response. Also, once the approach is finalized and approved, I will push any new commits and include the justification and description in the final commit message. On Mon, Aug 3, 2026 at 4:24 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
On Mon, Aug 03, 2026 at 01:45:44PM +0530, Srihari Parimi via Libguestfs wrote:
Hi Richard,
This is a more comprehensive description of the problem, where I respond to the specific issue and questions that you brought up during the discussion last week. I also cover the proposed solution towards the end. Kindly bear with the somewhat longish one
What thread is this all in response to ? AFAICT, there's nothing in the list archives with this subjct.
As Richard mentioned - https://github.com/libguestfs/virt-v2v/pull/160
- *[Comment 2] Confirming that the virtual machine Linux file format is fully compatible with the new directive* - Based on the analysis done for the previous comment, we can safely conclude that this problem is very specific to RHEL 7 only. Further, the problem occurs when following conditions are met - Source VM must be in UEFI boot mode - In the /etc/fstab, the /boot and /boot/efi partitions must be identified by the corresponding /dev/sd* files instead of the UUIDs (default) generated during FS creation. - The second condition forces virt-v2v conversion to configure GRUB. - As the grub configuration executes in context of libguestfs appliance (BIOS mode), it is generated with linux16, initrd16 whereas the VM is configured to boot in UEFI. - The VM powers up with UEFI firmware, but the linux16 directive switches the CPU into 16-bit real mode and look for BIOS services (/boot/grub2/i386-pc) which are absent.
- *[Comment 3] Regarding the potential modification of file system table entries and disk device naming conventions, Richard Jones insisted that any statements regarding potential disk access problems must be accompanied by a detailed explanation of the "why" and "what" behind those risks* - The kernel device discovery (names /dev/sd*) is non-deterministic as it is based on order of driver initialization at the boot time. The order variation is due to asynchronous driver probe, kernel update or VM configuration changes.
Conceptually I agree, but in practice this is does not look like an actual problem. If the original guest before v2v was using device names already, then it must have been OK, unless the guest was already broken in some way.
- By "hard-coding" the device names inside /etc/fstab, there could be a possibility of an unintended device being mounted onto an incorrect mount point, thus causing the system to fail or corrupt. - UUIDs (written into FS) are more reliable - where order of initialization would not matter making it more deterministic.
- *The proposed solution* - Convert the references to /dev/sd* files to corresponding FS UUIDs *[Implemented and tested]*
IMHO the use of device names vs UUIDs in an image is a end user choice, and v2v shouldn't really override that.
It looks like we must not convert device files to their corresponding UUIDs. Yes this seems to be safer approach.
- Following change applicable only if OS is RHEL 7 and Boot mode
is UEFI
- Replace {linux16, initrd16} with {linuxefi, initrdefi} *[Work in progress to change from using sed to using APIs]*
Rather than hardcoding that specific logic, why not query the original grub.conf and preserve what it used in the new config? Or not even re-generate grub.conf at all, instead replace the device paths inline ?
- There seems to be two ways to address - - Like you suggest, do not regenerate GRUB config - Avoid running grub2-mkconfig - if the source VM has {linuxefi, initrdefi}. This is possible if and only if source VM is RHEL 7 (verified in RHEL 7.9, RHEL 7.6) - virt-v2v in convert_linux.ml is already making a map of {source VM device files, Virtio Storage device files}. This could be used in the next step - This step Needs to be done: Inline replacement of device paths in /boot/efi/EFI/redhat/grub.cfg with corresponding virtio storage device (E.g. /dev/sda1 → /dev/vda1) - Problems: Directly parsing and editing grub.cfg - can cause missed references or path inconsistencies across custom kernel parameters. There are multiple modes of configuring GRUB - use of tools like grubby, anaconda kick start configuration, /etc/grub.d/<scripts> etc. - Let the grub2-mkconfig run - Check if the source VM uses {linuxefi, initrdef} in the grub.cfg and mark it so - Run the grub2-mkconfig (runs in libguestfs appliance context, BIOS boot mode) - If it was marked, then replace the {linux16, initrd16} with {linuxefi, initrdefi} - This approach is more deterministic for GRUB configuration. But we need to replace the GRUB directives (conditionally)
With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|