What is "Blockdev" in the context of PVE 9/QEMU 10?

[SInisterPisces]

Hello,

I'm watching the pve-devel mailing list, and there's a lot of work going on regarding "switching to blockdev" in the context of QEMU. I assume this is some sort of new framework/infrastructure for storage in QEMU 10.0 (which will most likely appear in PVE 9?) but I can't find any information on what exactly it is, given the infinite sea of search results that already exist for any variation of "QEMU block device."

Is there somewhere I can read more about this? It looks like a pretty huge change with touchpoints everywhere.

 

[fiona]

Hi,
it's nothing fancy, but for modernizing stuff. The modern -blockdev syntax is a prerequisite for some nice features however where the old -drive would not be enough (e.g. FUSE exports via storage daemon for TPM-as-qcow2, external qcow2 snapshot support), so it is well worth it.

From man kvm

   Block device options
       The QEMU block device handling options have a long history and have gone through several iterations as the feature set and com‐
       plexity of the block layer have grown. Many online guides to QEMU often reference older and deprecated options, which can  lead
       to confusion.

       The  most explicit way to describe disks is to use a combination of -device to specify the hardware device and -blockdev to de‐
       scribe the backend. The device defines what the guest sees and the backend describes how QEMU handles the data. It is the  only
       guaranteed stable interface for describing block devices and as such is recommended for management tools and scripting.

       The  -drive  option  combines the device and backend into a single command line option which is a more human friendly. There is
       however no interface stability guarantee although some older board models still need updating to work with the modern  blockdev
       forms.

       Older  options  like  -hda  are  essentially macros which expand into -drive options for various drive interfaces. The original
       forms bake in a lot of assumptions from the days when QEMU was emulating a legacy PC, they are not recommended for modern
       configurations.

 

[SInisterPisces]

Hi,
it's nothing fancy, but for modernizing stuff. The modern -blockdev syntax is a prerequisite for some nice features however where the old -drive would not be enough (e.g. FUSE exports via storage daemon for TPM-as-qcow2, external qcow2 snapshot support), so it is well worth it.

From man kvm

   Block device options
       The QEMU block device handling options have a long history and have gone through several iterations as the feature set and com‐
       plexity of the block layer have grown. Many online guides to QEMU often reference older and deprecated options, which can  lead
       to confusion.

       The  most explicit way to describe disks is to use a combination of -device to specify the hardware device and -blockdev to de‐
       scribe the backend. The device defines what the guest sees and the backend describes how QEMU handles the data. It is the  only
       guaranteed stable interface for describing block devices and as such is recommended for management tools and scripting.

       The  -drive  option  combines the device and backend into a single command line option which is a more human friendly. There is
       however no interface stability guarantee although some older board models still need updating to work with the modern  blockdev
       forms.

       Older  options  like  -hda  are  essentially macros which expand into -drive options for various drive interfaces. The original
       forms bake in a lot of assumptions from the days when QEMU was emulating a legacy PC, they are not recommended for modern
       configurations.

That sounds awesome. Thanks for the info!