Hello Community, We are observing that after a blockcopy, the disk backend will inherit from original disk's cache mode configuration even though a new cache mode is given. Specifically, the function https://github.com/libvirt/libvirt/blob/cd94d891fb4b5cdda229f58b1dee261d5514... which eventually calls qemuDomainPrepareDiskSourceData and override input config. My question is is this on purpose? Because seems like qemu allows different configs. Thnak you very much for the help. -- Best Regards, Jiatong Shen
On Wed, Nov 16, 2022 at 09:17:43 +0800, Jiatong Shen wrote:
Hello Community,
We are observing that after a blockcopy, the disk backend will inherit from original disk's cache mode configuration even though a new cache mode is given. Specifically, the function https://github.com/libvirt/libvirt/blob/cd94d891fb4b5cdda229f58b1dee261d5514... which eventually calls qemuDomainPrepareDiskSourceData and override input config. My question is is this on purpose? Because seems like qemu allows different configs. Thnak you very much for the help.
This is an historical artifact from the time when the block copy API used the 'drive-mirror' QMP API of qemu which didn't allow configuring any image specific parameters. Nowadays we use 'blockdev-mirror' which takes an image instantiated via 'blockdev-add' which can configure everything the same way as the disk, so it would be possible to honour the cache mode as specified in the block copy XML. Note that if you intend to implement it, the code must still preserve the original cache mode if the user doesn't specify it in the XML.
Thank you for the clarification. On Wed, Nov 16, 2022 at 5:11 PM Peter Krempa <pkrempa@redhat.com> wrote:
On Wed, Nov 16, 2022 at 09:17:43 +0800, Jiatong Shen wrote:
Hello Community,
We are observing that after a blockcopy, the disk backend will inherit from original disk's cache mode configuration even though a new cache mode is given. Specifically, the function
https://github.com/libvirt/libvirt/blob/cd94d891fb4b5cdda229f58b1dee261d5514...
which eventually calls qemuDomainPrepareDiskSourceData and override input config. My question is is this on purpose? Because seems like qemu allows different configs. Thnak you very much for the help.
This is an historical artifact from the time when the block copy API used the 'drive-mirror' QMP API of qemu which didn't allow configuring any image specific parameters.
Nowadays we use 'blockdev-mirror' which takes an image instantiated via 'blockdev-add' which can configure everything the same way as the disk, so it would be possible to honour the cache mode as specified in the block copy XML.
Note that if you intend to implement it, the code must still preserve the original cache mode if the user doesn't specify it in the XML.
-- Best Regards, Jiatong Shen
participants (2)
-
Jiatong Shen -
Peter Krempa