It's possible to reproduce this problem in a qemu-kvm guest, with an emulated disk: force the queue-length path selector.
# name=mfo-1704 # disk=/var/lib/libvirt/images/$name.qcow2 # iso=/var/lib/libvirt/images/zesty-server-ppc64el.iso.2017-03-14
# qemu-img create -f qcow2 $disk 128g
# virt-install \ --name $name \ --cdrom $iso \ --vcpus 8,sockets=1,cores=1,threads=8 \ --memory 8192 \ --controller type=scsi,model=virtio-scsi \ --disk format=qcow2,path=$disk \ --disk device=cdrom,readonly=true,path=$iso \ --network bridge=virbr0,model=virtio
Before the disk-detection stage (e.g., set-up users and passwords), Go Back, Execute a shell, and set up multipath.conf, and resume install:
~ # cat <<EOF >/etc/multipath.conf defaults { path_selector "queue-length 0" user_friendly_names yes find_multipaths no } EOF
~ # exit
It's possible to reproduce this problem in a qemu-kvm guest,
with an emulated disk: force the queue-length path selector.
# name=mfo-1704 lib/libvirt/ images/ $name.qcow2 lib/libvirt/ images/ zesty-server- ppc64el. iso.2017- 03-14
# disk=/var/
# iso=/var/
# qemu-img create -f qcow2 $disk 128g
# virt-install \ 1,cores= 1,threads= 8 \ model=virtio- scsi \ qcow2,path= $disk \ cdrom,readonly= true,path= $iso \ virbr0, model=virtio
--name $name \
--cdrom $iso \
--vcpus 8,sockets=
--memory 8192 \
--controller type=scsi,
--disk format=
--disk device=
--network bridge=
Before the disk-detection stage (e.g., set-up users and passwords),
Go Back, Execute a shell, and set up multipath.conf, and resume install:
~ # cat <<EOF >/etc/multipath .conf friendly_ names yes
defaults {
path_selector "queue-length 0"
user_
find_multipaths no
}
EOF
~ # exit