Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 15 additions & 8 deletions content/en/docs/v1/virtualization/cloneable-vms.md
Original file line number Diff line number Diff line change
Expand Up @@ -43,20 +43,21 @@ as an example.
name: sourcevm
namespace: tenant-root
spec:
external: true
externalMethod: PortList
disks:
- name: ubuntu-source
externalPorts:
- 22
disks:
- name: ubuntu-source
instanceProfile: ubuntu
instanceType: ""
running: true
runStrategy: Once
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Description: Find all VMInstance examples using running: true

echo "=== Files with 'running: true' in VMInstance specs ==="
rg -n 'running:\s*true' --type=md -C3

Repository: cozystack/website

Length of output: 5800


Update other documentation files to maintain consistency.

This PR updates the VMInstance examples to use runStrategy instead of running: true. However, several other v1 documentation files still use the old running: true field, creating inconsistency:

  • content/en/docs/v1/virtualization/proxmox-migration.md (line 137)
  • content/en/docs/v1/virtualization/windows.md (line 94)
  • content/en/docs/v1/virtualization/mikrotik.md (line 62)
  • content/en/docs/v1/virtualization/gpu.md (line 146)

Consider updating these files in a follow-up PR to ensure consistent guidance across all documentation.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@content/en/docs/v1/virtualization/cloneable-vms.md` at line 54, Several v1
doc pages still use the deprecated VMInstance field `running: true`; update
those VMInstance examples to use the `runStrategy` field (e.g., `runStrategy:
Once` or the appropriate strategy) instead. Edit the examples in the noted files
(content/en/docs/v1/virtualization/proxmox-migration.md, windows.md,
mikrotik.md, gpu.md) and replace `running: true` with the correct `runStrategy`
entry, keeping surrounding YAML structure and any comments intact so examples
remain valid.

sshKeys:
- <paste your ssh public key here>
external: true
resources:
cpu: "2"
memory: 4Gi
sockets: "1"
```
Comment on lines +46 to 61
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Description: Search for runStrategy usage patterns in the codebase and check for KubeVirt documentation

# Search for other runStrategy examples in documentation
echo "=== Searching for runStrategy usage in docs ==="
rg -n 'runStrategy:' --type=md

# Search for running: true usage in documentation
echo -e "\n=== Searching for running: true usage in docs ==="
rg -n 'running:\s*true' --type=md

# Search for instanceType examples
echo -e "\n=== Searching for instanceType usage patterns ==="
rg -nC2 'instanceType:' --type=md

Repository: cozystack/website

Length of output: 5857


🌐 Web query:

What are the valid values for runStrategy in KubeVirt VMInstance and what is the difference between runStrategy: Once and runStrategy: Always?

💡 Result:

runStrategy (on a VirtualMachine’s spec.runStrategy, which controls how its VirtualMachineInstance (VMI) is kept running) has five valid values: Always, RerunOnFailure, Once, Manual, Halted. [1][2]

Difference: Once vs Always

  • runStrategy: Once: the VM is started and runs a single time, and is not restarted when it completes—whether it ended in Success or Failure. [1][2]
  • runStrategy: Always: KubeVirt is tasked with keeping the VM running continuously by recreating (respawning) the VMI whenever it terminates, whether termination was controlled (e.g., guest-initiated shutdown) or uncontrolled (e.g., crash). This behavior is equivalent to the deprecated spec.running: true. [1]

Sources: KubeVirt Run Strategies user guide [1] and KubeVirt API reference (VirtualMachineSpec.runStrategy) [2].


Update runStrategy: Once to runStrategy: Always and remove empty instanceType field.

The file incorrectly uses runStrategy: Once on lines 54 and 152. According to the migration guide in content/en/docs/v1/operations/upgrades/_index.md (lines 76–77), the correct mapping is:

  • running: truerunStrategy: Always (keep VM running continuously)
  • running: falserunStrategy: Halted

runStrategy: Once runs the VM a single time and does not restart it—a different behavior than the original running: true.

Additionally, instanceType: "" on lines 53 and 151 uses an empty string. All other documentation examples provide actual instance types (e.g., "u1.medium", "u1.xlarge"). Either provide a value or omit the field entirely.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@content/en/docs/v1/virtualization/cloneable-vms.md` around lines 46 - 61,
Update the VM examples to use runStrategy: Always instead of runStrategy: Once
(replace both occurrences of the runStrategy field) to reflect running: true
semantics, and remove the empty instanceType: "" fields (or replace them with a
valid instance type like "u1.medium") where present so the examples don't
contain an empty string; look for the runStrategy and instanceType fields in the
cloneable-vms examples (both occurrences around the VM spec blocks) and apply
these two edits consistently.


When VM is created, it will get load balancer external IP address. You can get it using:
Expand Down Expand Up @@ -140,14 +141,20 @@ as an example.
spec:
external: true
externalMethod: PortList
externalPorts:
- 22
cloudInit: "hostname: my-cloned-vm"
cloudInitSeed: "1"
cloudInitSeed: "1" # This must be unique!
disks:
- name: ubuntu-cloned-1
externalPorts:
- 22
instanceProfile: ubuntu
running: true
instanceType: ""
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Using instanceType: "" is ambiguous. When defining resources manually with the resources block, it's clearer to omit the instanceType field. This allows it to use the default, which is then overridden by your specific resource requests. This avoids any confusion about what an empty instanceType implies. Please consider removing this line for clarity.

runStrategy: Once
resources:
cpu: "2"
memory: 4Gi
sockets: "1"

```

To ensure the cloned VM's network functions correctly, you must override its `hostname` via `.spec.cloudInit` and
Expand Down