[pve-devel] [PATCH qemu-server 02/14] blockdev: cmdline: convert drive to blockdev syntax

[Fiona Ebner]

Am 09.05.25 um 10:20 schrieb DERUMIER, Alexandre:
> -------- Message initial --------
> De: Fiona Ebner <f.ebner at proxmox.com>
> À: "DERUMIER, Alexandre" <alexandre.derumier at groupe-cyllene.com>, pve-
> devel at lists.proxmox.com <pve-devel at lists.proxmox.com>
> Objet: Re: [pve-devel] [PATCH qemu-server 02/14] blockdev: cmdline:
> convert drive to blockdev syntax
> Date: 08/05/2025 13:21:06
> 
> Am 06.05.25 um 17:40 schrieb DERUMIER, Alexandre:
>>>> Do we need to handle old client (for example, a pve8 doing a live
>>>> migrate + lcoal storage migration  sending a nbd:// uri to a pve9
>>>> with
>>>> blockdev support ) ?
>>
>> Thinking about this, maybe this is a good reason for version guard
>> too.
>> (so don't change from drive to blockdev during a live migration)
>>
>> I don't have tested, but I don't think that efi disk can mirrored &&
>> reattached from drive to blockdev, it's seem quite different and I'm
>> pretty sure that it could have border effects.
> 
>>> The EFI disk is not attached via -drive, but via -pflash. I don't
>>> think
>>> we should change that, just keep attaching via -pflash. Or does
>>> blockdev-mirror not work there? If we really need to change away from
>>> -pflash, then yes, we'll need to version guard.
> 
> mmmm, from what is see, , efidisk && ovmf  , are currently attached
> with -drive if=pflash

Oh sorry, I mistakenly thought this was a different option that didn't
use "-drive".

> 
> - drive 'if=pflash,unit=0,format=raw,readonly=on,file=/usr/share/pve-
> edk2-firmware//OVMF_CODE.fd' \
> -drive 'if=pflash,unit=1,id=drive-
> efidisk0,format=raw,file=/var/lib/vz/images/100/vm-disk-100-
> 0.raw,size=131072' \
> 
> 
> the blockdev part, are attached to -machine pflash0 && pflash1.
> 
> 
> +  -blockdev '{"cache":{"direct":true,"no-
> flush":false},"driver":"raw","file":{"cache":{"direct":true,"no-
> flush":false},"discard":"ignore","driver":"file","filename":"/usr/share
> /pve-edk2-firmware//OVMF_CODE.fd","node-name":"e-
> WxbgqVgkl6KMmuyWKSKESesSKws"},"node-name":"f-
> WxbgqVgkl6KMmuyWKSKESesSKws","read-only":true}' \
> +  -blockdev '{"driver":"throttle","file":{"cache":{"direct":true,"no-
> flush":false},"driver":"raw","file":{"cache":{"direct":true,"no-
> flush":false},"discard":"ignore","driver":"file","filename":"/var/lib/v
> z/images/100/vm-disk-100-0.raw","node-name":"e-
> 2lc6uRlbPUs6Si4A2GQOg0qicCW"},"node-name":"f-
> 2lc6uRlbPUs6Si4A2GQOg0qicCW","read-only":false},"node-name":"drive-
> efidisk0","throttle-group":"throttle-drive-efidisk0"}' \
> +  -machine 'pflash0=f-WxbgqVgkl6KMmuyWKSKESesSKws,pflash1=drive-
> efidisk0,type=pc+pve1'
> 
> 
> So, I think it's quite different internally.
> 
> (for example, they are an "size" option on drive not existing on
> blockdev for example, I have wrote details on the patch 3/14.)

I do think we still need the size (would need to be tested), because
OVMF would get confused when the image is padded/too large. The commit
message for 818ce80ec1a89c4abee61145c858b9323180e31b you mention in
03/14 describes this.

We might need to use a similar approach as proposed in
https://bugzilla.proxmox.com/show_bug.cgi?id=4693#c17 i.e. using
FUSE/NBD export for such images. Alternatively we could check how
difficult it would be to add a size setting for blockdev.

Mirror will fail when images have different sizes, AFAIK that is not
different for blockdev-mirror, it uses the same common code as
drive-mirror under the hood. This is
https://bugzilla.proxmox.com/show_bug.cgi?id=3227 One idea to fix that
was specifying a size when attaching the new target image, so again
unfortunate if blockdev doesn't support that.