[Bug 1893775] Comment bridged from LTC Bugzilla

Wed Sep 9 08:50:14 UTC 2020

------- Comment From MIHAJLOV at de.ibm.com 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.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to subiquity in Ubuntu.
https://bugs.launchpad.net/bugs/1893775

Title:
  [UBUNTU 20.04.1] Failure to install Ubuntu 20.04.1 as KVM guest on
  DASD

Status in Ubuntu on IBM z Systems:
  Triaged
Status in subiquity package in Ubuntu:
  Incomplete
Status in subiquity source package in Focal:
  Incomplete
Status in subiquity source package in Groovy:
  Incomplete

Bug description:
  ---Problem Description---
  Failure to install Ubuntu 20.04.1 as KVM guest on DASD

  ---uname output---
  Linux version 5.4.0-42-generic (buildd at bos02-s390x-003) (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)) #46-Ubuntu SMP Fri Jul 10 00:21:32 UTC 2020 (Ubuntu 5.4.0-42.46-generic 5.4.44)

  Machine Type = 3096-703 

  ---boot type---
  CDROM / ISO image

  ---Install repository type---
  Internet repository

  ---Install repository Location---
  ports.ubunut.com

  ---Point of failure---
  Other failure during installation (stage 1)

  I tried to install an Ubuntu 20.04.1 guest from ISO which failed.
  Steps to reproduce.
  1. Boot from ISO to start installer, in my case I used virt-install, but a manually defined libvirt domain has the same issue:
  $ virt-install --name focal.1 --memory 2048 --disk path=/dev/disk/by-path/ccw-0.0.a03f --cdrom ubuntu-20.04.1-live-server-s390x.iso

  2. On the installer screen, stay in simple mode and accept all
  defaults

  3. Shortly after a error pop-up appears, saying the installation has failed. Opening the log I see:
  ...
   storage:
     config:
     - {ptable: gpt, path: /dev/vda, wipe: superblock-recursive, preserve: false, name: '',
       grub_device: false, type: disk, id: disk-vda}
     - {device: disk-vda, size: 22153265152, wipe: superblock, flag: '', number: 1, preserve: false,
       type: partition, id: partition-0}
     - {fstype: ext4, volume: partition-0, preserve: false, type: format, id: format-0}
     - {device: format-0, path: /, type: mount, id: mount-0}
     version: 1
  ...
  An error occured handling 'format-0': OSError - could not get path to dev from kname: vda1
   finish: cmd-install/stage-partitioning/builtin/cmd-block-meta: FAIL: configuring format: format-0
   TIMED BLOCK_META: 1.942
   finish: cmd-install/stage-partitioning/builtin/cmd-block-meta: FAIL: curtin command block-meta

  It seems that the new installation procedure isn't correctly detecting virtio-attached DASDs and tries to handle them like SCSI disks (gpt label, ...). This is a regression compared to the debian-installer and prevents the installation of Ubuntu 20.04 KVM guests on DASD.

  I cross-checked by running the installation on a QCOW2 image, which
  succeeded without problems.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1893775/+subscriptions