Problem Statement: When a user creates a Virtual Machine from the OpenShift UI using the URL (creates PVC) option, there is no mechanism within the UI to handle HTTPS sources that use a custom (internal) CA or a self-signed certificate. This forces the user to switch to the CLI to manually patch the resulting DataVolume (DV) resource, which breaks the UI workflow.

Proposed Solution / RFE: Introduce new options in the "Create Virtual Machine" wizard on the "Disks" page, specifically when "URL (creates PVC)" is selected as the disk source.

Two potential options could be provided:

1. Checkbox for Insecure Connection:

•  Add a checkbox labeled "Skip TLS certificate verification".
• When checked, this would cause the auto-generated DataVolume to be created with the spec.source.http.insecureTLS: true flag (or an equivalent setting).

        Field for Custom CA:

• Add a field or button labeled "Upload custom CA certificate".
• This would allow the user to either upload a .crt file or paste the PEM-encoded certificate text.
• In the background, the UI/controller would:

1. 1. Automatically create a new ConfigMap in the VM's namespace containing this certificate.
   2. Set the spec.source.http.certConfigMap field on the auto-generated DataVolume to point to this new ConfigMap.

Justification & Use Case: This enhancement would significantly improve the user experience for end-users who may not be cluster administrators and do not have permission (or knowledge) to modify cluster-wide proxy settings.

• Keeps Users in the UI: This is the most significant benefit. It provides a complete, self-service workflow from the UI without needing CLI access or administrator intervention.

• Provides User Flexibility:
  • The "Skip TLS" option is highly valuable for development, testing, and lab environments where the security of the internal ISO server is not a primary concern.
  • The "Upload CA" option provides a secure and targeted solution. The user can supply the specific CA for their internal artifacts server without needing to trust that CA cluster-wide (which was the focus of the first RFE).
• Scalability: While it requires a user action for each VM (unlike the automatic trust from RFE 1), it is vastly more scalable and user-friendly than the current manual process of finding, editing, and patching DataVolume YAMLs.

This approach empowers the user directly at the point of creation, accommodating both secure (custom CA) and insecure (dev/test) enterprise environments.