On Mon, Jun 06, 2022 at 04:19:37PM +0200, Laszlo Ersek wrote:
Bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=2028764
I'm going to post the pre-requisite libguestfs-common and guestfs-tools
patches (one patch for each project) in response to this cover letter,
too.
I'm not sure why we want to perform the installation specifically at
*firstboot* <
https://bugzilla.redhat.com/show_bug.cgi?id=2028764#c2>.
Virt-v2v already only supports conversions where host and guest arches
are identical; thus, the appliance kernel could run native guest
binaries (if necessary). I've read
<
https://libguestfs.org/guestfs.3.html#running-commands>, but I'm not
overly convinced. Firstboot comes with *lots* of complications. Even
<
https://libguestfs.org/virt-builder.1.html#installing-packages>
mentions some of them:
> The downsides are that it will take the guest a lot longer to boot
> first time, and there’s nothing much you can do if package
> installation fails (eg. if a network problem means the guest can't
> reach the package repositories).
It is true that for Linux guests, and because virt-v2v assumes host
arch == guest arch, it is usually possible to run commands in the
guest at conversion time. This is why we can run (for example)
dracut/mkinitrd to regenerate the initramfs. Firstboot is mainly
useful for Windows where we cannot easily run Windows binaries at
conversion time.
It's possible there is still an issue with conversions where the host
kernel is older or newer than the guest kernel (especially older host)
and so might not be able to run the qemu-ga installation commands.
We've not seen that with dracut so far.
SELinux is mentioned in the bug, but should not be a concern.
(Virt-v2v runs commands in an appliance that has no SELinux, and we
relabel the guest filesystem after that.)
So firstboot shouldn't be necessary from a technical point of view.
OTOH ... my comment here:
https://bugzilla.redhat.com/show_bug.cgi?id=2028764#c2
was about more social issues where we've not been able to put the
qemu-ga RPMs on the ISO, and firstboot seemed like the easiest way to
get around that. AFAIK there is no way for a host subscribed to (eg)
RHEL 9 channels to download RHEL 7/8 RPMs. Maybe even hard to grab
SUSE or Debian packages.
Anyway, here goes.
I'll go ahead and review it as it is now!
Rich.
Thanks,
Laszlo
Laszlo Ersek (4):
output/create_libvirt_xml: wire up the QEMU guest agent
windows_virtio: remove "install_linux_tools"
convert_linux: extract qemu-guest-agent package name
convert_linux: install the QEMU guest agent with a firstboot script
common | 2 +-
convert/convert_linux.ml | 102 ++++++++++++++++++--
convert/linux.ml | 35 -------
convert/linux.mli | 11 ---
convert/windows_virtio.ml | 42 --------
convert/windows_virtio.mli | 4 -
output/create_libvirt_xml.ml | 11 +++
tests/test-v2v-i-ova.xml | 4 +
8 files changed, 111 insertions(+), 100 deletions(-)
--
2.19.1.3.g30247aa5d201
_______________________________________________
Libguestfs mailing list
Libguestfs(a)redhat.com
https://listman.redhat.com/mailman/listinfo/libguestfs
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages.
http://libguestfs.org