[Libguestfs] [v2v PATCH 0/4] convert_linux: install the QEMU guest agent with a firstboot script

[Laszlo Ersek]

On 06/07/22 15:07, Richard W.M. Jones wrote:
> On Tue, Jun 07, 2022 at 01:39:53PM +0100, Richard W.M. Jones wrote:
>> 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.
> 
> Just to clarify this.
> 
> Obviously virt-customize has an --install option which can install
> packages into Linux guests.  This works because the network is
> available and the yum/apt/etc commands within the guests are able to
> connect out to the distro package repositories.
> 
> Virt-v2v is however a bit special here.  While we might simply use the
> exact same method as virt-customize (and the network is also enabled),
> we have historically preferred not to do operations which require
> network access.
> 
> This is mainly for the benefit of Red Hat's downstream customers.
> They may run virt-v2v in an environment where there is no network, or
> the guest may not be subscribed to RHN without some manual
> intervention.

Thanks for the explanation, I now realize virt-customize runs in a quite
different context from that of virt-v2v. I don't intend to uproot that,
especially because the change could be very visible to customers. (We
seek to install qga by default, so network access would be kind of
"required" by default -- that probably wouldn't land well on conversion
servers on internal / isolated networks.)

> 
> I wonder if we want to revisit this assumption?  From an upstream
> point of view, using the network while virt-v2v is running to install
> qemu-ga from the distro repositories is fine (and considerably
> simpler).  Even from a downstream point of view I guess it would work
> in most cases, and maybe installing qemu-ga is a "nice-to-have" so as
> long as it doesn't hard-fail the whole conversion, would that be
> sufficient?  RH customers with isolated networks can install qemu-ga
> themselves using Ansible post-conversion scripts etc.

Well the last sentence could apply to the whole RFE BZ :) Let's see if I
can (slightly) rework this for a v2 instead.

Thanks,
Laszlo