[Bug 1893775] Comment bridged from LTC Bugzilla

[bugproxy]

------- Comment From cborntra at de.ibm.com 2020-09-07 11:05 EDT-------
> Request to always force ms-dos partition table in KVM was requested before.

Can you expain the context? The KVM team certainly did not request ms-
dos partition table.

> However, surely it is virtualization/layering violation, when a physical
> host device which is not virtio-scsi compatible is passed through to qemu
> which emulates it as scsi, despite the underlying device on the host not
> able to create GPT, extended partitions, etc.
>
> Can we please prohibit passing through /dev/dasda to qemu as virtio-scsi
> provider on qemu and/or virtio layer?
>
> If one passes /dev/dasda to qemu, it must show up as /dev/dasd* inside the
> guest too. As there is no way for the guest to know or figure out that the
> passthrough device is actually masquerading a dasd drive.
>
> Can you please explain again, why is it correct and desired to provide
> /dev/vda in the guest with /dev/dasda on the host, when the two types are
> incompatible with each other?

This is virtio-blk and virtio-blk has in QEMU special code to detect DASDs and will then also pass through geometry and block size.
This then allows the partition detection code and parted to detect this as a DASD. This did work in the past for all previous Ubuntu versions including 20.04, it does work with Redhat, Fedora and SUSE. parted has this detection and zipl has this detection. So it is far from being incompatible.

It is an important use case, because the majority of customers that also
have z/OS will usually use DASDs also for Linux. This allows them to
setup HA/failover solutions where the DASD is accessible from multiple
locations and the failover is orchestrasted by z/OS. This also avoids
the need for a shared filesystem.

Again: the old installer was able to handle this, the new one is not. It
was certainly expected that we get regressions with a new installer. The
right fix is not to discuss away useful features, instead the right
solution is certainly to fix things that are regressions. no?

-- 
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