Build and Publish Talos images for KubeVirt / Harvester / OpenShift Virtualization

[usrbinkat]

Feature Request

Requesting official images for kubevirt based hosting platforms.

Description

Kubevirt is gaining ground with a growing adopters list and commercialized platforms such as Rancher's Harvester and Red Hat's OpenShift Virtualization leading the way. Having a Sidero Labs Talos image officially built for this platform and published to a container registry for direct consumption would be a value add for the Talos community.

Images are trivially similar to OpenStack and ci build/test can be easily accommodated on kind kubernetes.

Kubevirt image CI testing examples:

• gh actions step
• run bats tests

Additional Information

• Sidero Slack #support thread

[smira]

I guess the question I still have is what exactly to publish:

• ISO
• vmlinuz + initramfs (like PXE booting)
• disk image

How should actually Talos node on kubevirt acquire machine config? talos.config= URL? mounted image with machine config? always in maintenance mode?

I think it makes sense to publish metal platform image.

[usrbinkat]

I do not see value in publishing the ISO for kubevirt, I believe we can cross that off the list.

we're working on an alternate route to supplying vmlinuz + initramfs to kubevirt, stay tuned for that but they will be published to container registry as it's native file type, not based on "containerized" files, so I think this would be redundant effort and depricated in the future.

Can talos pickup the talos.config from a local filesystem supplied via NoCloud or cloud-config/cloud-init? If so, we can store the config as a k8s secret and mount it into the VM at runtime.

finally, if working towards having a Talos Cluster API integration on the Kubevirt CAPI Provider is on the map then I suspect the maintenance mode / instance API driven configuration model will be required?

[smira]

I think nocloud is kind of overcomplicated to work with, as it also covers networking configuration.

It's not documented properly, but Talos can pick up machine config in metal mode from a mounted blockdevice with a specific partition label.

So we could publish regular metal image with a talos.config= URL set so that Talos picks it up from the volume. I never used kubevirt myself, so I'm lost on the options available.

It's not clear from the kubevirt docs what are the actual formats of images supported via container images, unless I completely missed that part.

We could also add kubevirt as a specific Talos platform and implement ways to get network and machine configuration which will work greate with kubevirt and kubevirt CAPI provider, but once again I need more details and pointers to the actual flows which work well with kubevirt.

[usrbinkat]

I think nocloud is kind of overcomplicated to work with, as it also covers networking configuration.

I have no strong opinion on this, what ever method is most sustainable gets my support.

It's not documented properly, but Talos can pick up machine config in metal mode from a mounted blockdevice with a specific partition label.

So we could publish regular metal image with a talos.config= URL set so that Talos picks it up from the volume. I never used kubevirt myself, so I'm lost on the options available.

If we can demonstrate this on Kubevirt I'd be happy to at least write a blog post for it.

It's not clear from the kubevirt docs what are the actual formats of images supported via container images, unless I completely missed that part.

Kubevirt's Containerized Data Importer supports:

• qcow2
• raw
• ISO
• xz and gz compressed versions of the above

Ref link: doc

We could also add kubevirt as a specific Talos platform and implement ways to get network and machine configuration which will work great with kubevirt and kubevirt CAPI provider, but once again I need more details and pointers to the actual flows which work well with kubevirt.

I'm very curious about this, I'll try to join the next office hours call to discuss further.

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 7 days with no activity.