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).
Anyway, here goes.
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