Description of problem: After importing a storage domain to a new RHEV-M, if a VM has two virtio-scsi disks attached, the VM will not boot. The console for the VM will fail with a "no bootable device" error. Even if the second, non-OS, disk is deactivate and the VM is started with *just* the OS disk activated, the VM hits the same error. Version-Release number of selected component (if applicable): rhevm-3.5.0 RHEL 7 hypervisor kernel-3.10.0-229.1.2.el7 vdsm 4.16.8.1-8.el7 How reproducible: Always for this customer Steps to Reproduce: 1. Import SD from Prod RHEV-M to DR 2. Import VMs 3. Try to start a VM with two virtio-scsi disks attached Actual results: VM does not boot Expected results: VM should boot Additional info: In testing this, the only common factor is that the VM(s) that have two virtio-scsi disks attached. If a vm has two virtio disks or one virtio and one virtio-scsi the VM boots just fine. The issue only appears when both disks are virtio-scsi. Further, in looking at the SPM the symlinks for the disks under the /rhev/data-center/... path are broken for the VMs that have two virtio-scsi disks.
It looks this this is already solved as part of https://bugzilla.redhat.com/1197444 with patch https://gerrit.ovirt.org/#/c/38242/ Since this bug is modified, I'm moving this bug also to Modify
(In reply to Maor from comment #3) > It looks this this is already solved as part of > https://bugzilla.redhat.com/1197444 with patch > https://gerrit.ovirt.org/#/c/38242/ > > Since this bug is modified, I'm moving this bug also to Modify Good! Aharon/Yaniv - can you please provide acks so this bug can be cloned and verified properly.
Tested using: ovirt-engine-3.6.0-0.0.master.20150519172219.git9a2e2b3.el6.noarch vdsm-4.17.0-822.git9b11a18.el7.noarch Verification instructions: 1. Import SD from Prod RHEV-M to DR 2. Import VMs 3. Try to start a VM with two virtio-scsi disks attached Results: VM with two virtio-scsi disks is bootable
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-0376.html