Enum variable of type qemuMigrationCapability is checked for zero in
src/qemu/qemu_migration_params.c:729.
"if (item->optional) { ..."
Actualy, QEMU_MIGRATION_CAP_XBZRLE enum constant has value 0.
So, at least, the condition is incorrect.
Adding QEMU_MIGRATION_CAP_NONE == 0 to enum has several a
On Tue, Apr 29, 2025 at 02:15:21PM +0100, Daniel P. Berrangé wrote:
> Since we deprecate and remove versioned machine types on a fixed
> schedule, we can automatically ensure that the docs reflect the
> latest version info, rather than requiring manual updates on each
> dev cycle.
>
> The first pa
On Tue, May 06, 2025 at 05:00:19PM +0100, Daniel P. Berrangé wrote:
> Since we deprecate and remove versioned machine types on a fixed
> schedule, we can automatically ensure that the docs reflect the
> latest version info, rather than requiring manual updates on each
> dev cycle.
>
> The first pa
> On Sun, Apr 27, 2025 at 19:48:07 +0800, honglei.wang(a)smartx.com wrote:
>
> Don't forget to move this to the 11.4 section. the 11.3 release is
> already in freeze.
OK, thanks for the reminder.
Ideally, we should use names like nvme0n1, which follow the typical naming
convention for NVMe devices (even if they don't necessarily match the actual
device names inside the guest). However, using this approach in libvirt would
tightly couple the device name with the controller relationship, m
>
> Hmm, does bootindex even work here? Shouldn't the bootindex apply to the
> controller instead?
>
Both nvme and nvme-ns devices can have bootindex specified, and the
corresponding fw_cfg entries will be generated. I think it's more appropriate
for us to specify the boot order at the disk l
