OK this doesn't seem right. I think there's a bug here but before I alter system state I want to capture as much debug info as possible. # ls -lsh 50G -rw-r--r--. 1 root root 37P Jul 22 13:23 uefi_opensuseleap42.2a3-1.qcow2 196K -rw-r--r--. 1 root root 193K Jul 22 08:46 uefi_opensuseleap42.2a3-2.qcow2 # df -h /dev/sda5 104G 67G 37G 65% / Host= Fedora 24 Guest = openSUSE Leap 42.2 alpha failed installation, the ISO media has been verified Steps: 1. # qemu-img create -f qcow2 -o nocow=on uefi_opensuseleap42.2a3-1.qcow2 50G # qemu-img create -f qcow2 -o nocow=on uefi_opensuseleap42.2a3-2.qcow2 50G 2. Both of these back virtio disks, appearing as vda and vdb in the guest. 3. In the guest, I ask YaST to use both vda and vdb, create an EFI System partition for both drives, and the rest of the free space on both drives become md members set to RAID level1. Then I start the installation. 4. At some point well past midway I get an rpm I/O error, none of this environment state survives except what might appear in the host's journal. After the error, YaST wouldn't continue so I chose the power off option. The two obvious problems are the difference in qcow2 file sizes, as if the md RAID setup didn't work correctly. But I'm going to set aside the 2nd qcow2 not having been written to at all since it was created, and deal with this 37 Petabyte qcow2. 5. When I change to a Fedora 24 Workstation ISO to boot the VM, it fails to start, complaining about qcow2 corruption. Jul 22 13:27:12 f24m libvirtd[924]: failed to connect to monitor socket: No such process Jul 22 13:27:12 f24m libvirtd[924]: internal error: process exited while connecting to monitor: 2016-07-22T19:27:12.502777Z qemu-system-x86_64: -drive file=/var/lib/libvirt/images/uefi_opensuseleap42.2a3-1.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,cache=unsafe,aio=threads: qcow2: Image is corrupt; cannot be opened read/write Jul 22 13:27:12 f24m virtlogd[3118]: End of file while reading data: Input/output error So I'm looking for the culprit. Chances are a qcow2 file growing to 37 Petabytes is not exclusively user error. -- Chris Murphy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
