-
Notifications
You must be signed in to change notification settings - Fork 105
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
design-proposal: persist-vmi-firmware-uuid
This proposal introduces a mechanism to persist the firmware UUID of a Virtual Machine (VM) in KubeVirt. By storing the firmware UUID, we ensure that it remains consistent across VM restarts, which is crucial for applications and services that rely on the UUID for identification or licensing purposes. Signed-off-by: Daniel Sionov <[email protected]>
- Loading branch information
Showing
1 changed file
with
91 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,91 @@ | ||
# Overview | ||
This proposal introduces a mechanism to persist the firmware UUID of a Virtual Machine (VM) in KubeVirt. By storing the firmware UUID, we ensure that it remains consistent across VM restarts, which is crucial for applications and services that rely on the UUID for identification or licensing purposes. | ||
|
||
## Motivation | ||
In the current implementation, the firmware UUID of a Virtual Machine Instance (VMI) is generated dynamically during the creation of the VMI. This means that if the generation logic is changed in the future, it may receive a new firmware UUID. This behavior can cause issues for applications that depend on a stable UUID. | ||
Furthermore, we plan to enhance the firmware UUID generation logic to include the VM's Name and Namespace, ensuring uniqueness across different namespaces. However, changing the generation logic could inadvertently assign new UUIDs to existing VMs upon restart, leading to potential disruptions. | ||
By persisting the firmware UUID in the VM's status, we can maintain consistency across restarts and future-proof existing VMs against changes in the UUID generation logic. | ||
|
||
## Goals | ||
- Persist Firmware UUID: Store the firmware UUID within the VM's status to ensure it remains consistent across VM restarts. | ||
- Maintain Backward Compatibility: Ensure that existing VMs without a persisted firmware UUID continue to operate without issues. | ||
- Prepare for Future Enhancements: Allow for future changes to the firmware UUID generation logic without impacting existing VMs. | ||
|
||
## Non Goals | ||
- Changing Firmware UUID Generation Logic Now: This proposal does not include modifying the current firmware UUID generation to incorporate vm.Name and vm.Namespace. | ||
- Altering VM Spec: No changes will be made to the VM specification or require user intervention to set or manage the firmware UUID. | ||
|
||
## Definition of Users | ||
End Users: Individuals or organizations running VMs on KubeVirt who require consistent firmware UUIDs for their applications. | ||
|
||
## User Stories | ||
As an end-user, I expect my VM to maintain its identity across restarts. | ||
|
||
## Repos | ||
Kubevirt/kubevirt | ||
|
||
# Design | ||
We will introduce a new field FirmwareUUID in the status section of the VirtualMachine resource. | ||
The virt-controller will use this field to persist the firmware UUID (if its empty) | ||
|
||
## API Examples | ||
**Example VM Status** | ||
|
||
```yaml | ||
apiVersion: kubevirt.io/v1alpha3 | ||
kind: VirtualMachine | ||
metadata: | ||
name: mytestvm | ||
spec: | ||
runningStrategy: Halted | ||
template: | ||
spec: | ||
architecture: arm64 | ||
domain: | ||
devices: | ||
disks: | ||
- name: disk1 | ||
disk: | ||
bus: virtio | ||
interfaces: | ||
- name: network1 | ||
bridge: {} | ||
networks: | ||
- name: network1 | ||
multus: | ||
networkName: mytestvm/mytestvm | ||
volumes: | ||
- name: disk1 | ||
emptyDisk: | ||
capacity: 50G | ||
status: | ||
created: true | ||
desiredGeneration: 2 | ||
observedGeneration: 2 | ||
printableStatus: ErrImagePull | ||
runStrategy: Once | ||
firmwareUUID: "123e4567-e89b-12d3-a456-426614174000" | ||
|
||
``` | ||
|
||
## Scalability | ||
The proposed changes have no anticipated impact on scalability capabilities of the KubeVirt framework | ||
|
||
## Update/Rollback Compatibility | ||
New API so should not affect updates / rollbacks. | ||
|
||
## Functional Testing Approach | ||
first create a vm, start the vm, ensure vm.Status contains firmwareUUID field, and it is populated correctly, | ||
restart vmi and verify firmwareUUID uuid has been reused using unit test. | ||
|
||
# Implementation Phases | ||
1. API Extension: | ||
Add the FirmwareUUID field to the VirtualMachineStatus struct. | ||
|
||
2. Controller Logic Update: | ||
Modify the virt-controller to check for vm.Status.FirmwareUUID. | ||
Implement logic to generate and persist the UUID when necessary. | ||
|
||
3. Testing: | ||
Develop unit tests for the new controller logic. | ||
Write functional tests to validate end-to-end functionality. |