Why choosing QEMU directly instead of the virtualisation stack

Why I chose QEMU directly instead of the virtualisation stack Today I finally settled the question: QEMU directly vs libvirt/virt-manager , especially for a Windows work VM stored on a USB stick. Short answer: for this use case, QEMU + one good script beats the whole virtualisation stack. My context The VM disk ( LCS.raw ) lives on a USB partition (label: LCS_RAW ). I want a “VM on a stick”: plug USB anywhere → mount → run → done. It’s one VM, always the same, for client work (Windows + browser). I don’t need snapshots, multi-VM orchestration, XML configs, etc. Why I didn’t want libvirt / virt-manager here 1. libvirt assumes “local, permanent storage” Libvirt stores VM definitions in XML pointing to fixed paths like: /var/lib/libvirt/images/windows.qcow2 My VM is on a removable USB , which might be: /dev/sda2 today /dev/sdb2 tomorrow /media/ernest/Whatever if Plasma mounts it /mnt/LCS when I mount it manually Libvirt and virt-manager don’...
0

Firmware management: fwupdmgr

To upgrade the firmware, you can use the fwupdmgr command.

Install it:
$ sudo apt install fwupd

Get a list of devices that support firmware updates with fwupdmgr:
$ fwupdmgr get-devices

Get the status of the devices if they have an available firmware update:
$ fwupdmgr get-updates

Install all available updates:
$ fwupdmgr update

Manually pass the device IDS of the devices you want to be updated:
$ fwupdmgr update <DEVICE IDS>

Comments

Post a Comment