centos8 stream as virt-launcher base image?

77 views
Skip to first unread message

Cole Robinson

unread,
Mar 8, 2021, 2:00:46 PM3/8/21
to kubevirt-dev
Hi all. I've been thinking about whether kubevirt would benefit from
moving the virt-launcher container base image from fedora to centos8
stream. Mainly with the intention of making it easier to get access to
latest qemu and libvirt packages for dev, CI, etc.

Some context: Right now the virt-launcher container uses fedora:32, with
RHEL8-AV qemu + libvirt, rebuilt for fedora and published in copr repos:
https://copr.fedorainfracloud.org/groups/g/kubevirt/coprs/

centos8 stream doesn't ship RHEL8-AV though. There's plans to start
shipping it in a virt-sig style repo for centos stream. When that exists
it should cover some, possibly all, of the RHEL-AV rebuild content in
copr. Example existing virt-sig repo for centos 8.3:
http://mirror.centos.org/centos-8/8.3.2011/virt/x86_64/advanced-virtualization/

Longer term, when centos stream is fully operational, and
pre-RHEL-release virt content is pushed there regularly, the copr repos
may be entirely redundant. When devs need new libvirt or qemu packages
for PRs or local dev, they may already be available in stream repos. For
virt packages in centos8 stream that could be a while though, maybe even
centos9 stream timeframe, so this is just conjecture.

Thoughts? Anyone know of any definite blockers, or particular
difficulties lurking?

Thanks,
Cole

Alice Frosi

unread,
Mar 9, 2021, 3:56:51 AM3/9/21
to Cole Robinson, Adam Litke, kubevirt-dev
I'd like also to point that what Cole is doing might be also valuable for CDI.
Right now, CDI is based on Fedora 33, and it doesn't use qemu/libvirt, but only qemu-img, and nbdkit. However, if in the future we plan to integrate other virtualization tools, like for example libguestfs, this implies qemu as a dependency.

Thanks,

Alice

--
You received this message because you are subscribed to the Google Groups "kubevirt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubevirt-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubevirt-dev/737804eb-aa0e-ce94-ab8f-e0042b5067d6%40redhat.com.

Mazzystr

unread,
Mar 9, 2021, 10:06:27 AM3/9/21
to Cole Robinson, kubevirt-dev
Do we ever consider building upon an alternative img (ie. Alpine, Cirros)?

dvo...@redhat.com

unread,
Mar 10, 2021, 8:45:50 AM3/10/21
to kubevirt-dev
This transition makes sense to me. As long as the centos stream packages are fully backwards compatible with what we're using today (pretty sure they are), i don't see any blockers.

The centos streams sounds like a great balance to me. We continue to consume stable virt packages while getting new features backports at a faster cadence. 


 


Thanks,
Cole

dvo...@redhat.com

unread,
Mar 10, 2021, 8:47:41 AM3/10/21
to kubevirt-dev
On Tuesday, March 9, 2021 at 10:06:27 AM UTC-5 Chris C wrote:
Do we ever consider building upon an alternative img (ie. Alpine, Cirros)?

We're actually building on a scratch image now and pulling in dependencies from the fedora repos.  So we techincally aren't using any base image. 

Cole Robinson

unread,
Mar 10, 2021, 12:43:57 PM3/10/21
to Mazzystr, kubevirt-dev
On 3/9/21 10:06 AM, Mazzystr wrote:
> Do we ever consider building upon an alternative img (ie. Alpine, Cirros)?
>

I'm not sure if it's ever been considered. A limiting factor for the
virt-launcher image is availability of libvirt and qemu builds that
behave in the way kubevirt currently expects: binaries in certain
locations, qemu with certain machine types, etc. Those builds are only
currently available for Fedora/CentOS/RHEL

- Cole

Fabian Deutsch

unread,
Mar 11, 2021, 4:37:08 AM3/11/21
to Cole Robinson, Mazzystr, kubevirt-dev
Yes, that's really the driving factor here: The availability of an up to date, reasonably tested stream of libvirt/qemu and the combination with a container base image.

We have seen that there have been struggles in the past to get the right versions, and to get even some backports to the libvirt versions we were using - this worked out because several people jumped in to make this happen.

I'm in favor of this change because it helps us to get into a more streamlined consumption of the desired packages.
 

- Cole


--
You received this message because you are subscribed to the Google Groups "kubevirt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubevirt-dev...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages