Hi All, I have in config of 2 Xen DomU's this disk: <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/dev/mapper/keys'/> <target dev='xvdz' bus='xen'/> <readonly/> </disk> If I start the DomU's then all starts without problem, see this in log of the DomU: { "pdev_path": "/dev/mapper/keys", "vdev": "xvdz", "backend": "qdisk", "format": "raw", "removable": 1, "discard_enable": "False", "colo_enable": "False", "colo_restore_enable": "False" } but this disk isn't there in the domU... Why? It is a shared disk between the DomU's but configured as "readonly" so there shouldnt be a problem (with the same xen xl configuration, there is no problem) -- ------ Greetz
On 8/27/20 3:49 AM, Christoph wrote:
Hi All,
I have in config of 2 Xen DomU's this disk:
<disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/dev/mapper/keys'/> <target dev='xvdz' bus='xen'/> <readonly/> </disk>
Using blkback works for me, e.g. <driver name='phy'...>.
If I start the DomU's then all starts without problem, see this in log of the DomU:
{ "pdev_path": "/dev/mapper/keys", "vdev": "xvdz", "backend": "qdisk", "format": "raw", "removable": 1, "discard_enable": "False", "colo_enable": "False", "colo_restore_enable": "False" }
but this disk isn't there in the domU... Why?
It appears readonly disks only work with blkback.
It is a shared disk between the DomU's but configured as "readonly" so there shouldnt be a problem (with the same xen xl configuration, there is no problem)
What xl config did you use? It doesn't work for me if I specify qdisk and readonly. E.g. the following does not work "backendtype=qdisk,format=raw,vdev=xvdz,access=ro,target=..." Regards, Jim
Using blkback works for me, e.g. <driver name='phy'...>.
what is the diff to 'qemu'?
What xl config did you use? It doesn't work for me if I specify qdisk and readonly. E.g. the following does not work
"backendtype=qdisk,format=raw,vdev=xvdz,access=ro,target=..."
"phy:/dev/mapper/keys,xvdz,r" Greetz
On 8/27/20 2:47 PM, Christoph wrote:
Using blkback works for me, e.g. <driver name='phy'...>.
what is the diff to 'qemu'?
It's just a different block backend. Xen supports both qemu as a block backend and blkback. blkback only supports raw IIRC. And apparently, when used with Xen, the qemu backend only support rw.
What xl config did you use? It doesn't work for me if I specify qdisk and readonly. E.g. the following does not work
"backendtype=qdisk,format=raw,vdev=xvdz,access=ro,target=..."
"phy:/dev/mapper/keys,xvdz,r"
As expected you are using blkback. Regards, Jim
On 8/27/20 11:53 PM, Christoph wrote:
"phy:/dev/mapper/keys,xvdz,r"
As expected you are using blkback.
hm then it seems that there is a bug in domxml-from-native virsh translation... I've done the xml config with: virsh domxml-from-native xen-xl...
If your disk XML contains <driver name='qemu'/>, which your earlier example did, then the conversion is correct since it maps to backendtype=qdisk. If however your XML contains <driver name='phy'/> and it maps to backendtype=qdisk, then we have a bug. Regards, Jim
If your disk XML contains <driver name='qemu'/>, which your earlier example did, then the conversion is correct since it maps to backendtype=qdisk. If however your XML contains <driver name='phy'/> and it maps to backendtype=qdisk, then we have a bug.
my native configuration has: "phy:/dev/mapper/keys,xvdz,r" and virsh domxml-from-native ... has converted ist to <driver name='qemu'/> so I think this is a bug...
On 9/3/20 6:33 AM, Christoph wrote:
If your disk XML contains <driver name='qemu'/>, which your earlier example did, then the conversion is correct since it maps to backendtype=qdisk. If however your XML contains <driver name='phy'/> and it maps to backendtype=qdisk, then we have a bug.
my native configuration has:
"phy:/dev/mapper/keys,xvdz,r"
and virsh domxml-from-native ...
has converted ist to <driver name='qemu'/>
so I think this is a bug...
Agreed. Can you also enter an issue in the libvirt gitlab project for this bug? Alternatively, feel free to open a bug at bugzilla.opensuse.org if you already have an account. Regards, Jim
participants (2)
-
Christoph -
Jim Fehlig