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.
- *[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.
- 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 ? 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 :|