Bug 1929158

The tools are installed automatically by virt-v2v. Changing product and component.

"Red Hat Virtualization Tools" means RHEV-APT?  At some point in the
past we were told this needed to be installed.

This tool was used for automatic update of drivers and installation of guest agents. It was essential in RHV 4.3 and earlier. But with the recently done changes and improvements we don't rely on it anymore.

- virt-v2v now installs qemu-ga
- RHV no longer ships guest tools ISO
- auto-attach feature for ISO was also removed
- drivers are now updated by windows update

Because of all the above rhev-apt serves little purpose and we may consider removing it from virt-v2v.

This is good - removing code is easy!  When can we assume that no one
will be running RHV 4.3 any longer?

@rjones: I mean package, which is installed with virtio drivers during migration. Customer is removing them manually after migration, because he do not have usage for them.

And, for you: "When can we assume that no one will be running RHV 4.3 any longer?" - this means you want/need to wait until end of end of life of 4.3? Is it possible to create patch just for customer? Or version of virt-v2v depending on RHV4.4?

(In reply to mheppler from comment #7)
> @rjones: I mean package, which is installed with virtio drivers
> during migration. Customer is removing them manually after migration,
> because he do not have usage for them.

I'm very unclear what this paragraph means.  "package" is RHEV-APT or something else?
Virtio drivers are required to boot the guest, it simply won't work otherwise (or
might work, but run very slowly).

> And, for you: "When can we assume that no one will be running RHV 4.3 any
> longer?" - this means you want/need to wait until end of end of life of 4.3?
> Is it possible to create patch just for customer? Or version of virt-v2v
> depending on RHV4.4?

Well we cannot break virt-v2v for RHV 4.3 customers.  Installing RHEV-APT
on RHV 4.4 doesn't actually matter - it's unnecessary but won't break anything.
So we will not make this change in RHEL until no customers are running
RHV 4.3 any longer.

I looked at the case and they are using RHV 4.3 and it seems they have problem with all the "applications" that are installed by rhev-apt after the conversion from guest tools ISO. While it is true that they could be OK with having drivers that were injected by virt-v2v and possibly don't need all the agents, they still need ovirt/rhev guest agent or qemu guest agent installed in the VM. Because the environment is RHV 4.3/RHEL 7, there is no other way how to get the guest agent into the VM without rhev-apt. vir-v2v in RHEL 8 knows how to install qemu-ga directly from the ISO, but this was not backported to RHEL 7 (and I have no idea how feasible it would be to do so).

Since this is RHEL 7 material (and the bug should be retargeted) I cannot suggest removing rhev-apt from virt-v2v as this would break installation/auto-update for other customers. But with the previously mentioned functionality (installing qemu-ga from ISO) we might be able to suggest some workarounds to this customer.

Finally, as this is not discussed in the case, do we know what is the customers motivation for removing the applications? The disk/memory footprint of all that should be minimal, so is it perhaps security related issue?

OK, I am not talking about virtio drivers - this is essential part. Which package... I attach screenshots from customer, this is the best and I should have done it in the beginning. My fault.

I understand the breaking of 4.3 is not acceptable now - there are many users and this is important functionality. This is why I am asking for patch. But support RHV4.3 is very important issue and I will send update to customer in this way. Workaround should be for example some domain policy, if they have a domain controller.

Thanks, mheppler

Created attachment 1758202 [details]
package names

Created attachment 1758203 [details]
package names

If anything this is a question for the RHV team.  Virt-v2v installs
virtio drivers which are required to get the guest to boot, and RHEV-APT
which is required for RHV 4.3 (see discussion above).  So there's no
bug in virt-v2v as far as I'm concerned.

Maybe the best way forward here is:

 - Try to understand exactly why the customer is concerned about these
   applications.  As Tomas said above, is it because there's too much
   memory used?  Disk space?  Security?  What is their exact concern?

 - Work with the customer and RHV team to discuss which applications are
   safe to remove after conversion, or if there is some way to avoid
   RHEV-APT from installing them in the first place.

Yes, this is not a bug, this is much more feature request of a customer. Here is answer to question "Why":

```
Isn't it possible to fix it just for us?
I don't know exactly which part of the software provides it,
but it wouldn't be possible to control this behavior with some parameters or modify the whole rpm package for us?

The main reason is that RHV Tools are no longer needed in RHV 4.4 and we do not want to install something in the OS that is not needed there.
At the same time, we would do the work of uninstalling and probably restarting in addition

We have active directory domain but I don't think it's a good solution.
```

(the last sentence is about domain controller and its policy as a tip for workaround)

If I read this discussion, everything is pointing to answer "not possible for now" (because of RHV4.3)... OK. In this case, is it possible to find some workaround for customer?

I looked again at the customer case and I am quite confused if this is RHV 4.3 or RHV 4.4 environment. Could you please confirm whether

- it is 4.3 or 4.4?
- do they have RHEL 7 or RHEL 8 conversion hosts?

They have a RHV 4.4 and conversion hosts based on RHEL 8. They upgraded from RHV4.3 (and rhel 7) to 4.4 (and 8).

I see, sorry for the confusion. That changes the situation. So there are two workarounds the customer could use to avoid installing the components:

1) Don't use RHV guest tools ISO -- they can remove RHV guest tools ISO from the ISO domain and use virtio-win ISO in its stead. That way they will only see QEMU guest agent and RHEV-APT installed. Depending on the cluster level, if they ever add the RHV guest tools ISO to the domain again at some point in the future, the tools may be installed.

2) Remove RHEV-APT installer -- if they remove /usr/share/virt-tools/rhev-apt.exe from their conversion host only QEMU guest agent will be installed. virt-v2v will only produce a warning that it could not find rhev-apt.exe but the conversions should otherwise succeed. But note that this essentially breaks the virt-v2v RPM. Once virt-v2v RPM is updated/reinstalled on the host rhev-apt.exe will be restored!

Created attachment 1780334 [details]
packages available on system