On Wed, Jan 11, 2023 at 10:24:30AM -0500, Stefan Hajnoczi wrote: > On Tue, Jan 10, 2023 at 03:29:47PM +0000, Daniel P. Berrangé wrote: > > On Tue, Jan 10, 2023 at 10:19:51AM -0500, Stefan Hajnoczi wrote: > > > Hi Peter, > > > Zoned storage support > > > (https://zonedstorage.io/docs/introduction/zoned-storage) is being added > > > to QEMU. Given a zoned host block device, the QEMU syntax will look like > > > this: > > > > > > --blockdev zoned_host_device,node-name=drive0,filename=/dev/$BDEV,... > > > --device virtio-blk-pci,drive=drive0 > > > > > > Note that regular --blockdev host_device will not work. > > > > > > For now the virtio-blk device is the only one that supports zoned > > > blockdevs. > > > > Does the virtio-blk device expowsed guest ABI differ at all > > when connected zoned_host_device instead of host_device ? > > Yes. There is a VIRTIO feature bit, some configuration space fields, > etc. virtio-blk-pci detects when the blockdev is zoned and enables the > feature bit. I get a general sense of unease when frontend device ABI sensitive features get secretly toggled based on features exposed by the backend. When trying to validate ABI compatibility of guest configs, libvirt would generally compare frontend properties to look for differences. There are a small set of cases where backends affect frontend features, but it is not that common to see. Consider what happens if we have a guest running no zoned storage, and we need to evacuate the host to a machine without zoned storage available. Could we replace the stroage backend on the target host with a raw/qcow2 backend but keep pretending it is zoned storage to the guest. The guest would continue making its I/O ops be batched for the zoned storage, which would be redundant for raw/qcow2, but presumbly should still work. If this is possible it would suggest the need to have explicit settings for zoned storage on the virtio-blk frontend. QEMU would "merely" validate that these settings are turned on, if the host storage is zoned too. > > > This brings to mind a few questions: > > > > > > 1. Does libvirt need domain XML syntax for zoned storage? Alternatively, > > > it could probe /sys/block/$BDEV/queue/zoned and generate the correct > > > QEMU command-line arguments for zoned devices when the contents of > > > the file are not "none". > > > > > > 2. Should QEMU --blockdev host_device detected zoned devices so that > > > --blockdev zoned_host_device is not necessary? That way libvirt would > > > automatically support zoned storage without any domain XML syntax or > > > libvirt code changes. > > > > > > The drawbacks I see when QEMU detects zoned storage automatically: > > > - You can't easiy tell if a blockdev is zoned from the command-line. > > > - It's possible to mismatch zoned and non-zoned devices across live > > > migration. > > > > What happens with existing QEMU impls if you use --blockdev host_device > > pointing to a /dev/$BDEV that is a zoned device ? If it succeeds and > > works correctly, then we likely need to continue to support that. This > > would push towards needing a new XML element. > > Pointing host_device at a zoned device doesn't result in useful behavior > because the guest is unaware that this is a zoned device. The guest > won't be able to access the device correctly (i.e. sequential writes > only). Write requests will fail eventually. > > I would consider zoned devices totally unsupported in QEMU today and we > don't need to worry about preserving any kind of backwards compatibility > with --blockdev host_device,filename=/dev/my_zoned_device. So I guess I'm not so worried about host_device vs zoned_host_device, if we have explicit settings for controlled zoned behaviour on the virtio-blk frontend. I feel like we should have something explicit somewhere though, as this is a pretty significant difference in the storage stack, that I think mgmt apps should be aware of, as it has implications for how you manage the VMs on an ongoing basis. We could still have it "do what I mean" by default though. eg the virtio-blk setting defaults could imply "match the host", so we get effectively a tri-state (zoned=on/off/auto) With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
