Libguestfs - Dec 2021 - [v2v PATCH v2] convert_linux: translate the first CD-ROM's references in boot conf files

On 12/16/21 12:08, Laszlo Ersek wrote:
> But, I'm attaching the full conversion log too. (NB this log was
generated with my patch applied; however, the patch itself makes no difference
regarding the boot failure, as stated before.)
> 
> FWIW, I don't know if this warning (i.e., the failed attempt to mount
/dev/sda) has anything to do with the boot failure in the converted guest.
Apologies for conversing with myself :/

Noticed this (a bunch of it) in the log:
>   WARNING: PV /dev/sda2 in VG VolGroup00 is using an old PV header, modify
the VG to update.
I don't know if we ultimately perform any operation that modifies the volume
group, but if we do, it seems plausible that that update prevents the LVM driver
in RHEL5 from recognizing the volume group again :(

Laszlo

On Thu, Dec 16, 2021 at 12:12:33PM +0100, Laszlo Ersek
wrote:
> On 12/16/21 12:08, Laszlo Ersek wrote:
> 
> > But, I'm attaching the full conversion log too. (NB this log was
generated with my patch applied; however, the patch itself makes no difference
regarding the boot failure, as stated before.)
> > 
> > FWIW, I don't know if this warning (i.e., the failed attempt to
mount /dev/sda) has anything to do with the boot failure in the converted guest.
> 
> Apologies for conversing with myself :/
> 
> Noticed this (a bunch of it) in the log:
> 
> >   WARNING: PV /dev/sda2 in VG VolGroup00 is using an old PV header,
modify the VG to update.
> 
> I don't know if we ultimately perform any operation that modifies the
volume group, but if we do, it seems plausible that that update prevents the LVM
driver in RHEL5 from recognizing the volume group again :(
This does indeed seem like a new problem (in LVM).  I don't think
we've seen this one before so it needs a bug to track it.

About the patch: The fact that there's an existing bug does not block
this patch from going upstream.  It doesn't seem as if this patch is
the cause.

About device name translation:

This is something of a mess at the moment.  There's a lot of history ...

Originally I didn't think very deeply about how device names
should be represented in the API.  For example if you had an
API like

  int guestfs_mount (guestfs_h *g, char *device, char *mp)

how should the device name be represented?  In the original version it
was basically the QEMU / kernel name, probably "/dev/vda1".  When we
switched to using virtio-scsi the device names changed ("/dev/sda1"),
but that was fine I just added some code which spotted
/dev/[hsv]... and translated it inside the daemon.  (This is what
"device name translation" does).

Informally I said that "/dev/sda" in the API means the "first
disk",
(in the sense of "added first using guestfs_add_drive")
"/dev/sdb"
means second disk, "/dev/sda4" means the fourth partition of the first
disk and so on.  This was a convention but it wasn't encoded or
enforced anywhere.

That all worked for quite a long time, but then the kernel started to
enumerate devices in parallel, so now if you two disks, you could no
longer assume that the "first disk" might randomly appear as /dev/sda
or /dev/sdb.

We're still sending these strings across from the library to the
daemon, but now we do some additional and very hokey translation using
device serial numbers which you can check in the code
(daemon/device-name-translation.c)

I think what we _should_ be doing is translating the strings into an
internal representation, which we'd use inside the library and
serialise into the daemon.  This is, naturally, an awful lot of work.

Note that the ABI cannot be changed, so whatever happens we're still
going to be passing strings to guestfs_* APIs, this is all about what
happens internally after that point in the generated code.

There's the additional complication that not everything mountable is a
disk (eg. LVs, /dev/md*).  Matt Booth already separated that out with
a distinction between disks and "mountables".

There's also the issue that we always add a hidden disk for the
appliance, which is added after the other drives.  We need to ignore
that.

There's also disk hotplugging which we should deprecate - it was a
failed experiment, and indeed has never worked for the direct backend
which is enough justification to replace those APIs with ones which
print an error and return -1.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v