We install agents during Windows v2v conversions so the converted VMs are fully functional on boot (qemu/ovirt-ga, drivers, rhv-apt for updates) Such functionality is missing for Linux OSes as the expectation was that such systems are already using update mechanism and you install required tools post conversion. For smoother experience we want to install guest agents (drivers are not needed) during the conversion so we do not require/risk online operations to install the packages, or require manual actions post conversion. Easiest option seems to be to just include Linux ovirt-guest-agent and qemu-guest-agent on Windows tools iso as we make it available for v2v already. It's helpful to have even an outdated version as it would then update automatically once the converted VMs are fully functional and online (this is the same for Windows)
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
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:)
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.
(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.
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.
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.
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.
Ok, requirements are complete now. Lev, can you estimate how much time this change needs?
(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.
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
I will check the version once we have a VM with v2v running.
Verified on WGT 4.3-2 ISO that QEMU guest agent is included. This bug is not about functional testing which Meitals team will be doing.
IIUC, this RFE is the one we should verify https://bugzilla.redhat.com/show_bug.cgi?id=1620594 which is in "new" status. functional testing of this feature will be done accordingly.
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-2019:1054