So the history of this msdos/dasd partitioning table stuff in the old installer were as follows:

LTC-135429 https://bugs.launchpad.net/ubuntu/+source/partman-partitioning/+bug/1534629
LTC-136054 https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1527328
https://bugs.launchpad.net/ubuntu/+source/partman-partitioning/+bug/1537942
LTC-137464 https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1548411
LTC-149975 https://bugs.launchpad.net/ubuntu/+source/partman-partitioning/+bug/1650300
https://bugs.launchpad.net/ubuntu/+source/partman-base/+bug/1595495
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815916

partman-partitioning (110ubuntu3) xenial; urgency=medium

  * Set s390x partitioning tables (parted label type) to dasd. LP:
    #1534629, LP: #1527328, LP: #1537942.

 -- Dimitri John Ledkov <email address hidden>  Tue, 09 Feb 2016 19:32:43 +0000

partman-partitioning (110ubuntu4) xenial; urgency=medium

  [ Viktor Mihajlovski ]
  * Revert to using msdos partitioning table on s390x as a fallback,
    however use dasd partitioning table if advised to do so by
    partman. LP: #1548411

 -- Dimitri John Ledkov <email address hidden>  Mon, 29 Feb 2016 14:27:51 +0000

partman-partitioning (112ubuntu1) yakkety; urgency=medium

  * Resynchronise with Debian.  Remaining changes:
    ....
    - On s390x use msdos partition table by default, unless partman
      advises dasd.

 -- Dimitri John Ledkov <email address hidden>  Fri, 12 Aug 2016 09:52:51 +0100

But also this:

partman-base (190) unstable; urgency=medium

  [ Viktor Mihajlovski ]
  * Add disk label type to device directory, such that
    e.g. partman-partitioning can elect dasd partitioning table for dasd
    drives.

  [ Dimitri John Ledkov ]
  * On s390[x], prevent using extended partitions on DASD drives that can
    only hold 3 partitions. Parted doesn't have special knowledge about
    that and claims that msdos partition table on DASD drives can hold
    the usual maximum number of partitions types.

 -- Christian Perrier <email address hidden>  Sun, 13 Nov 2016 07:45:31 +0100

The code there is:

s390|s390x)
                if [ -e ./label ]; then
                    disklabel=$(cat label)
                fi
                # FBA devices have parted label dasd, but should not use dasd
                # partition table. Maybe FBA|ECKD type should be exposed by
                # partman-base and/or parted. LP: #1650300
                device=$(sed 's|.*/||' ./device)
                if grep -q "(FBA ).*$device" /proc/dasd/devices; then
                    disklabel=msdos
                fi
                if [ "$disklabel" != dasd ]; then
                    disklabel=msdos
                fi
                echo $disklabel;;

In partman-base we also limit msdos to primary partitions only on dasd
+#ifdef __s390__
+                  /* DASD drives can only do 3 partitions */
+                  && strcmp(disk->dev->model, "IBM S390 DASD drive")
+#endif

and disk label is saved to a file.

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.

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
- dasd ECKD devices must use vfio-ccw if passed directly to KVM, and uses dasd partition table
- 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
- passing through dasd devices as virtio-scsi in the guest must not be allowed
- 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.

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.