Changing boot order from inside a VM

[NdK73]

Hello all.

Is it possible to let a VM tell Proxmox "from now on, boot from network instead of from scsi0"?
For servers with IPMI it can be done via ipmitool, but for VMs?

Tks,
Diego

 

[bbgeek17]

You'd ssh/https out to PVE and execute either QM or API command to modify VM config.

There is also an IPMI virtual simulator that appears to work in some way with QEMU/KVM but I don't know how many modifications you'd have to put in place to make it play nice with PVE.

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[NdK73]

Urgh. Having to expose PVE to "public" access is "not very good". Actually just a bit less bad than exposing IPMI.
But if it's not (yet?) managed by agent interface there's not much I can do

Tks.

 

[bbgeek17]

The QEMU agent is also not meant to be accessed from inside the VM. The idea is for one way communication from hypervisor host to the guest.

In theory the VM should be completely isolated from the infrastructure/hypervisor. The boot parameters would need to be exposed through BIOS that would be somehow exposed to the VM OS. I guess if there was demand for such functionality the Open Source community would implement it.

If dynamic change of boot order by VM consumer is a requirement for you, creating a simple authenticated web page that would proxy such requests may be a solution? Just throwing out an idea.

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[esi_y]

Hello all.

Is it possible to let a VM tell Proxmox "from now on, boot from network instead of from scsi0"?
For servers with IPMI it can be done via ipmitool, but for VMs?

Tks,
Diego

What is the objective? Make a reboot into a different OS? Why not set priority of boots PXE first, then SCSI? Instead then manage it on the PXE server (whether offer anything at all)?

 

[NdK73]

The QEMU agent is also not meant to be accessed from inside the VM. The idea is for one way communication from hypervisor host to the guest.

Uh? Guest ACKs fs freeze/thaw and reports its IP addresses (and other infos) to the host via agent, IIUC. So it's already bi-directional.

In theory the VM should be completely isolated from the infrastructure/hypervisor. The boot parameters would need to be exposed through BIOS that would be somehow exposed to the VM OS. I guess if there was demand for such functionality the Open Source community would implement it.

Well, even if completely isolated (like when there's no agent), is there no way to tell it to interact with its own BIOS settings?

If dynamic change of boot order by VM consumer is a requirement for you, creating a simple authenticated web page that would proxy such requests may be a solution? Just throwing out an idea.

That's a whole can of worms in its own (automating (re)installs with FAI/Saltstack). Where do I keep the secrets to authenticate the machine?

 

[NdK73]

What is the objective? Make a reboot into a different OS? Why not set priority of boots PXE first, then SCSI? Instead then manage it on the PXE server (whether offer anything at all)?

Handle automated reinstallation of the OS, initiated by the guest itself. But not every boot have to be a reinstall. Changing the boot order is usually the easiest thing to do.

 

[leesteken]

On a SeaBIOS VM, I would expect the VM to have zero boot order influence, like the BIOS of old. And I can imagine work-around via communication with the Proxmox host.
On OVMF (UEFI), the VM does have access to (virtual) EFI variables, which usually define the boot order. Proxmox stores these variables on the "EFI Disk". I don't know if there is a way to tell Proxmox not to use the boot order from the GUI; maybe uncheck everything in the GUI or put something in args?
It does not seem impossible to have the VM determine the boot order (when using OVMF) and if it's not yet possible, maybe it's a reasonable feature request?