Bug 1637534

Hi Michael,

as I understand this, this would be RHEL only as we probably cannot install a RHEL guest-agent package on another Linux distro (rpm, dependencies, python versions, libraries, etc.)

As RHEL already ships the guest agent rpms by default, why not just "injecting" them from the default RHEL channels (and probably add the "rpm" itself to RHVH if such hosts are needed for conversion).

I don't think the Windows ISO would be the best location for these packages.

Thanks!
Martin

(Originally by Martin Tessun)

v2v supports debian/ubuntu and we do have agent built for it - that can be included too.

channels are not really solving the problem. We need the rpm (not installed) and we need them on each hypervisor
We can discuss which agents to include, it is possible qemu-ga from 7.6 would be ok and then we won't need ovirt-ga (at least not for the important functionality)

Dunno...if we stop calling it "Windows ISO" and just call it "guest tools ISO" I do not see any issues:)

(Originally by michal.skrivanek)

After discussing the whole usecase for the conversion, we came up with the following needs to the ISO:

- 2 rpm-packges of qemu-ga for init-based systems and systemd based systems:
  - latest RHEL 6 qemu-guest-agent package
  - latest RHEL 7 qemu-guest-agent package
- 2 deb-packages to cover Debian based releases (init and systemd).

With that we would be able to easily migrate systems to RHV and have the basic guest monitoring functionality available as well, esp. the IP address reporting.

(Originally by Martin Tessun)

(In reply to Martin Tessun from comment #4)
> After discussing the whole usecase for the conversion, we came up with the
> following needs to the ISO:
> 
> - 2 rpm-packges of qemu-ga for init-based systems and systemd based systems:
>   - latest RHEL 6 qemu-guest-agent package

Which means inherit from qemu-kvm-0.12.1.2-2.506.el6_10.1 build:
- qemu-guest-agent-0.12.1.2-2.506.el6_10.1.x86_64.rpm
only or do we also need:
- qemu-guest-agent-0.12.1.2-2.506.el6_10.1.ppc64.rpm ?



>   - latest RHEL 7 qemu-guest-agent package

Which means inherit from qemu-guest-agent-2.8.0-2.el7_5.1 build:
- qemu-guest-agent-2.12.0-2.el7.x86_64.rpm
only or do we also need:
- qemu-guest-agent-2.12.0-2.el7.ppc64le.rpm
- qemu-guest-agent-2.12.0-2.el7.ppc64.rpm


> - 2 deb-packages to cover Debian based releases (init and systemd).

which we don't have in brew and need to be built somehow in our system unless someone can confirm we can ship binaries downloaded from debian servers within a Red Hat product.

Please define which version and which architectures should we ship:
https://packages.debian.org/search?keywords=qemu-guest-agent

> With that we would be able to easily migrate systems to RHV and have the
> basic guest monitoring functionality available as well, esp. the IP address
> reporting.

(Originally by Sandro Bonazzola)

virt-v2v only exists on x86_64 and it only makes sense to move
x86_64 guests because VMware only exists on x86_64, so no other
architectures need to be taken into account at this time.  We might
in RHEL 8.1 support aarch64 although that is not certain.

I would just copy the binary packages from Debian, although make
sure to include a link back to the source package in Debian in a
README file so that we are complying with the GPL.

(Originally by Richard Jones)

There's no requirement to build anything or pull things from brew. We just need "a" version and we do not have to really follow updates. It is probably better to use a fixed well-working version as we will be deploying those agents to all y-stream versions anyway.

(Originally by michal.skrivanek)

Hi Sandro,

mainly see C#6 and C#7 which are pretty much complete from my pov.

(In reply to Sandro Bonazzola from comment #5)
> (In reply to Martin Tessun from comment #4)
> > After discussing the whole usecase for the conversion, we came up with the
> > following needs to the ISO:
> > 
> > - 2 rpm-packges of qemu-ga for init-based systems and systemd based systems:
> >   - latest RHEL 6 qemu-guest-agent package
> 
> Which means inherit from qemu-kvm-0.12.1.2-2.506.el6_10.1 build:
> - qemu-guest-agent-0.12.1.2-2.506.el6_10.1.x86_64.rpm
> only or do we also need:
> - qemu-guest-agent-0.12.1.2-2.506.el6_10.1.ppc64.rpm ?
> 
> 
> 
> >   - latest RHEL 7 qemu-guest-agent package
> 
> Which means inherit from qemu-guest-agent-2.8.0-2.el7_5.1 build:
> - qemu-guest-agent-2.12.0-2.el7.x86_64.rpm
> only or do we also need:
> - qemu-guest-agent-2.12.0-2.el7.ppc64le.rpm
> - qemu-guest-agent-2.12.0-2.el7.ppc64.rpm
> 

Only x86  packages are required, as v2v is currently only fully supported for x86.

> 
> > - 2 deb-packages to cover Debian based releases (init and systemd).
> 
> which we don't have in brew and need to be built somehow in our system
> unless someone can confirm we can ship binaries downloaded from debian
> servers within a Red Hat product.
> 
> Please define which version and which architectures should we ship:
> https://packages.debian.org/search?keywords=qemu-guest-agent
> 

I would go with the latest stable release (looks to be stretch currently).

> > With that we would be able to easily migrate systems to RHV and have the
> > basic guest monitoring functionality available as well, esp. the IP address
> > reporting.

(Originally by Martin Tessun)

Ok, requirements are complete now. Lev, can you estimate how much time this change needs?

(Originally by Sandro Bonazzola)

(In reply to Sandro Bonazzola from comment #9)
> Ok, requirements are complete now. Lev, can you estimate how much time this
> change needs?

I think that we can add RHEL QemuGA packages within 1-2 weeks.

Debian one is more complicate issue, as we discussed, since I'm quite concerned with the security issue of containing that way or another binary packages built by 3rd party.

As discussed one of the options will be a more complicated process of rebuilding the package from source and then verifying the hashes, since these should match due to the modified build tools. We'll then need to extract the hash from the signed DEB package, and if that matches, we could include it.

To implement this process will take more time of course, unless somebody is ready to OK inclusion of the binary packages upstream, and e.g. only verify it's signature.

(Originally by Lev Veyde)

Hi Peter, 

can you please check that this iso has correct version?

Meital's team will take care of functional v2v testing.
As discussed on Integration Planning.

Thanks

(Originally by Lukas Svaty)

I will check the version once we have a VM with v2v running.

(Originally by Petr Matyas)

Verified on WGT 4.2-9 ISO that QEMU guest agent is included.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:3493