[FEATURE] Support virtual media mount

[starbops]

Is your feature request related to a problem? Please describe.

This long-awaited feature could make several virtual machine provisioning use cases possible. With this feature implemented, we will be able to dynamically attach an ISO image to the target virtual machine and boot from it.

Describe the solution you'd like

My initial thought is, this will need a third-party storage solutions to handle the volume lifecycle. We should do our best to make our part as neutral as possible, at least giving users the ability to choose which solution to use via configuration. As I use Harvester a lot, Longhorn seems a good fit. However, CDI could also be a valid candidate. With that said, both are a bit overkill for our use case. If this is infeasible or intolerable, we must handle the image and volume ourselves.

Describe alternatives you've considered

N/A

Additional context

This is one of the remaining item from #2.

[starbops]

This is how people deal with virtual media mount with the sushy-tools BMC emulator, hope this can shed some lights:
https://docs.openstack.org/sushy-tools/latest/user/dynamic-emulator.html#virtual-media-resource

[MartijnStraatman]

I read something about a storage requirement. Maybe a solution could be something like this

virtctl image-upload pvc live-iso-sno  \
  --size 2Gi --storage-class ocs-storagecluster-ceph-rbd \
  --access-mode ReadWriteOnce \
  --image-path rhcos-4.14.0-x86_64-live.x86_64.iso

Storage must be available then through pvc's.

[anishbista60]

@starbops I have couple of question.

• IMO, we need to extend the VM object api to add the iso section in the CRD or do we need to implement this in our kubevirtbmc schema ?
• What sort of field we should mention in the schema , so that we can provide the granular opportunity to end user. Therefore , they can decide the what backend provider to use and which storage.

My rough schema looks like

type ISOAttachmentSpec struct {
    // Source of the ISO image - users can choose one of the following
    // Only one source should be specified
    PersistentVolumeClaim *PVCSource    `json:"persistentVolumeClaim,omitempty"`
    URL                   *URLSource     `json:"url,omitempty"`
    ConfigMap             *ConfigMapSource `json:"configMap,omitempty"`
    
    // Storage class to use when creating new PVCs (if needed)
    StorageClassName      *string        `json:"storageClassName,omitempty"`
    
    // Storage provisioner specific options
    StorageOptions        map[string]string `json:"storageOptions,omitempty"`
    
    // Boot order priority
    BootOrder             *uint          `json:"bootOrder,omitempty"`
    
    // Additional attachment options
    ReadOnly              bool           `json:"readOnly,omitempty"`
}

// PVCSource represents an existing PVC as the ISO source
type PVCSource struct {
    Name      string `json:"name"`
    Namespace string `json:"namespace,omitempty"`
}

// URLSource represents an ISO that should be downloaded from a URL
type URLSource struct {
    URL      string `json:"url"`
    // Storage requirements for the downloaded ISO
    Size     string `json:"size,omitempty"`
}


// ConfigMapSource represents ISO data stored in a ConfigMap
type ConfigMapSource struct {
    Name     string `json:"name"`
    Key      string `json:"key,omitempty"`
}

and storage provider configuration .

type OperatorConfig struct {
    // existing fields...
    
    // ISO Storage configuration
    ISOStorage ISOStorageConfig `json:"isoStorage"`
}

type ISOStorageConfig struct {
    // Default storage class to use for ISO images
    DefaultStorageClass string `json:"defaultStorageClass,omitempty"`
    
    // Available storage providers
    Providers []StorageProviderConfig `json:"providers"`
    
    // Caching configuration
    CacheSize string `json:"cacheSize,omitempty"`
    CachePath string `json:"cachePath,omitempty"`
}

type StorageProviderConfig struct {
    // Name of the storage provider
    Name string `json:"name"`
    
    // Type of provider (longhorn, cdi, hostpath, nfs, etc.)
    Type string `json:"type"`
    
    // Provider-specific configuration
    Config map[string]string `json:"config,omitempty"`
    
    // Storage classes associated with this provider
    StorageClasses []string `json:"storageClasses,omitempty"`
}

[starbops]

@anishbista60 Thanks for the input. I'm afraid I forgot to attach the relevant Redfish documentation regarding bare-metal provisioning. Here it is: https://www.dmtf.org/sites/default/files/standards/documents/DSP2046_2024.4.html#virtualmedia-164

In the context of typical bare-metal provisioning, the virtual media mount functionality provided by the BMC can let the operator instruct the server to remotely mount an ISO image so that they can install the OS on the server. This is another way to provision bare-metal servers in contrast to PXE booting. Here, we'd like to have a similar capability for virtual machines.

IMHO, the key is to design the innerworkings of KubeVirtBMC's virtbmc component (agent), to support the VirtualMedia Redfish resource (properties and actions). You can get a sense of how server vendors support this functionality by taking a look at their published documentation:

• https://www.dell.com/support/manuals/en-us/idrac9-lifecycle-controller-v4.x-series/idrac9_4.00.00.00_redfishapiguide_pub/virtualmedia?guid=guid-44720af7-7951-49b2-89fc-01181a0edf92&lang=en-us&lwp=rt
• https://github.com/HewlettPackard/python-ilorest-library/blob/master/examples/Redfish/mount_virtual_media_iso.py
• https://www.supermicro.com/manuals/other/redfish-ref-guide-html/Content/general-content/virtual-media-management.htm

You'll notice that the above are all client side stuff. That's because the server side implementation is mostly proprietary and baked into the BMC. This is the real issue we're tackling here.

[anishbista60]

@starbops Cool. Thanks, I was searching for more information . Now, looking forward to it .

[starbops]

Is this correct ?

Looks like it, though I feel setting the boot order and rebooting the VM are kind of outside the scope of this virtual media mount functionality.

Which storage solution need to be implemented ? Right now I am doing it via PVC.

IMO, we may stick to PVC as the interface and assume the image is already provisioned somewhere in the system. It's also okay to integrate some storage solution to a certain degree, i.e., download the image and populate a volume for PVC to refer to. The former is more neutral and flexible; the latter is more integrated and user-friendly.