-
Bug
-
Resolution: Done
-
Undefined
-
6.18.0
-
8
-
False
-
rubygem-foreman_kubevirt-0.5.0
-
Satellite Rocket Sprint 14, Satellite Rocket Sprint 15
-
sat-rocket
-
None
-
None
-
None
-
Automated
Description of problem:
Currently the image based provisioning in foreman_kubevirt is utilizing a containerDisk, which is an ephemeral, shared volume that can be used to boot machines.
However, image based provisioning in Foreman/Satellite is usually a "golden image" style provisioning: a given disk image is copied and the new, writable, copy is used to boot the VM.
To achieve this workflow, a DataVolume needs to be created using a DataVolumeTemplate with its "DataSource" pointing at an existing DataVolume
spec:
dataVolumeTemplates:
- apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
creationTimestamp: null
name: centos-stream9-amd64-chocolate-halibut-57
spec:
sourceRef:
kind: DataSource
name: centos-stream9-amd64
namespace: openshift-virtualization-os-images
storage:
resources:
requests:
storage: 30Gi
runStrategy: RerunOnFailure
How reproducible:
Always
Is this issue a regression from an earlier version:
Steps to Reproduce:
1. Create a host under OCP-V
2. Select an image
3. Click build
Actual behavior:
The host will not be created and will report errors around improper disk definition.
Or, if the host creation succeeds (as the error is just a length check failing, so it can succeed), you get a system with a wrong rootdisk type.
Expected behavior:
A host is created using the image as a template. And the resulting host disk is not ephemeral.
The user is enabled to configure the size/storage class of the created volume