Comment 15 for bug 1893775

------- Comment From <email address hidden> 2020-09-09 04:38 EDT-------
(In reply to comment #20)
[...]
trimming for readability
>
> It is extremely limiting if installer cannot create/recreate/reformat the
> drive, and has such hardcoded bad guesses.
>
> In the past, qemu did not have vfio-ccw, but now it does. Surely, the new
> libvirt/qemu in focal, when given a --disk
> path=/dev/disk/by-path/ccw-0.0.1601 it must be emulating vfio-ccw if at all
> possible as then on the guest it would appear as a /dev/dasda, and be
> correctly processed.
First, vfio-ccw hasn't yet reached a maturity level comparable to that of virtio, which is in production since years. Forcing customers to use that as a full replacement for virtio is not appropriate at this point in time.
Second, it's about commonality. Customers do not want to treat KVM guests differently on Z than on other platforms. Virtio-blk was always the first choice to pass in host block devices, and DASDs are for sure block devices.
Third, the idea to infer from the device node the characterics of the device is not a concept that can applied universally. ATA devices mutated from /dev/hdx to /dev/sdx, without becoming 'real' SCSI devices. You can attach an DVD device or ISO as virtio-blk, and you can still not assume it can hold a partition table of any kind, etc.
>
> So on s390x, the old installer
> - default to use ms-dos partition table, with primary partitions only, with
> default layout having less than 4 partitions.
> - if previously detected DASD partition table, use DASD, unless operating on
> FBA in that case use msdos again
>
> The above I think was ultimately driven by "lowlevel formateded FBA or ECKD
> drives" without a dasd partition table. In such cases, it was reported in
> qemu/kvm as "unknown" and thus "msdos with 3 partitions" was used which
> seemed to work, but is extremely fragile.
>
> In the new installer, I do no wish to support partition tables that are
> limited by a very small upper bound of 2TiB. My laptop has that, and it's
> trivial to over-provision/thinly provision such sizes.
>
> Is it reasonable to say that:
> - nvme, zfcp, virtio-scsi will use GPT
This is still postulating an identity of transport and device characteristics, at least for virtio-scsi, it is perfectly valid to attach any kind of block device as a virtio-scsi LUN. It is likely safe to assume that NVME and FCP attached device have fixed block and not ECKD characteristics. Conceptually it is not clean, and assumptions like these are still hampering the proliferation of true 4K sector devices
> - dasd ECKD devices must use vfio-ccw if passed directly to KVM, and uses
> dasd partition table
NO, see above, it is not acceptable to take away the possibility from customers to use DASD in their environment
> - If vfio-ccw is not available, one can partition it on the host, create LVM
> or ext4 storage pool, and passthrough LVM volume or qcow2 file via
> virtio-scsi
Apart from the regression itself, this is impractical in many cases. Customers with DASD are in most cases also running z/OS. z/OS is able to handle the 'partitions' (for z/OS they are datasets) of a CDL formatted ECKD DASD.
> - passing through dasd devices as virtio-scsi in the guest must not be
> allowed
I doubt that this would be acceptable to the QEMU community, see above as well.
> - dasd FBA is still confusing to me as it seems to not support neither dasd
> nor gpt partition table
>
> Or what are you proposing we should be using across all storage variants,
> with/without passthrough?
>
> I am interested to know what should be used for DASD-FBA passthrough from
> host to guest as virtio-scsi.
At least for KVM this is not a real world issue. FBAs only exist as emulated devices (EDEVs)for z/VM guests, there's no storage server I'm aware of implementing CCW FBA devices.
>
> I am also interested to know if we can pass more information from host to
> guest via virtio-scsi to indicate what sort of backing storage is in use. If
> it's zfcp, nvme, DASD-ECKD, DASD-FBA, whether or not it has been low-level
> formatted or not (even if it's not possible to initiate low-level formatting
> from the guest), etc. As it still feels like there is a lot of blind
> guesswork in side the guest, which is limiting our installers to tiny disk
> sizes.
Valid questions. But I fear this is beyond the scope of the issue at hand (time- and content wise). I would strongly recommend to use a heuristic to identify ECKD DASD based on parted's DASD label detection. Ideally, regardless of the transport, but at least for virtio-attached storage. As even the biggest DASDs tend to be far smaller than your desktop's multi-terabyte HDD/SDD, there' no fear of introducing artificial limits there.