Bug 982455 - RHEL Guest fails to boot after attaching 200+ scsi devices [virtio-scsi qcow2]
RHEL Guest fails to boot after attaching 200+ scsi devices [virtio-scsi qcow2]
Status: CLOSED DEFERRED
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Libvirt Maintainers
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-09 02:08 EDT by chandrashekar shastri
Modified: 2016-04-09 20:14 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-04-09 20:14:06 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
xml (2.78 KB, application/x-bzip2)
2013-07-09 02:08 EDT, chandrashekar shastri
no flags Details

  None (edit)
Description chandrashekar shastri 2013-07-09 02:08:01 EDT
Created attachment 770800 [details]
xml

Description of problem:

The Guest fails to boot when 200+ scsi devices are attached and rebooted the VM.

When we attach [hot-add] the devices to the guest after running the rescan or 
echo ' - - - ' > /sys/class/scsi_host/host#/scan, all the devices gets recogized in the guest. But when we reboot the guests it fails to boot by throwing an error as " Boot failed: not a bootable disk ". 

I have attached the xml of the guest and below is the script that is used to create 256 qcow2 images and attaches to the specified VM.

####################################################

#!/usr/bin/bash
if [ x$1 != x ]; then
cmd=$1
c=1
while [ $c -le 256 ]
do
qemu-img create -f qcow2 /home/virtio-scsi$c.qcow2 1G
#sleep 1
i="`cat file | head -$c | tail -1`"
virsh attach-disk $cmd /home/images/virtio-scsi$c.qcow2 $i --persistent  --cache writethrough --sourcetype file --driver qemu --subdriver qcow2
#virsh detach-disk $cmd $i
 ((c++))
done
else
echo "enter the vm name"
fi

####################################################

Libvirt : 1.0.6
commit f2eaef3f0e4181f7528d946e97927d342be73942

qemu : 1.5.50
commit 945dad6d9d795f03fd839c6e36cc883b3839f5e5

Kernel : 3.10.0-rc5+


Steps to Reproduce:
1. Create 256 qcow2 images
2. Hot-add the devices [virtio-scsi] 
3. Run the rescan-scsi-bus.sh or echo ' - - - ' > /sys/class/scsi_host/host#/scan command to make sure that the devices are getting added to the guest.
4. Reboot the guest and observe that it fails to boot.
Comment 1 chandrashekar shastri 2013-07-09 02:31:39 EDT
If we detach all the added devices then the guest will boot properly.
Comment 2 Jiri Denemark 2013-07-09 02:39:26 EDT
What if you remove the <boot dev='hd'/> element from the XML and add <boot order='1'/> element directly to the disk that the guest is supposed to boot from? Assuming it's hda, its XML would be

    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/rhel64-64-vm.img'/>
      <target dev='hda' bus='ide'/>
      <boot order='1'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>

Does it work after this change?
Comment 3 chandrashekar shastri 2013-07-09 08:18:57 EDT
I edited the boot order and still getting the same issue:

Part of the xml file is here:

<domain type='kvm' id='7'>
  <name>rhel64-64-vm</name>
  <uuid>47feb0e1-0c43-9be9-da12-2ead34864de2</uuid>
  <memory unit='KiB'>4096000</memory>
  <currentMemory unit='KiB'>2048000</currentMemory>
  <vcpu placement='auto'>1</vcpu>
  <numatune>
    <memory mode='strict' nodeset='0'/>
  </numatune>
  <resource>
    <partition>/machine</partition>
  </resource>
  <os>
    <type arch='x86_64' machine='pc-i440fx-1.5'>hvm</type>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='none'/>
      <source file='/home/images/rhel64-64.qcow2'/>
      <target dev='hda' bus='ide'/>
      <boot order='1'/>
      <alias name='ide0-0-0'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <disk type='block' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <alias name='ide0-1-0'/>
      <address type='drive' controller='0' bus='1' target='0' unit='0'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='writethrough'/>
      <source file='/home/images/virtio-scsi1.qcow2'/>
      <target dev='sdb' bus='scsi'/>
      <alias name='scsi0-0-0-1'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
Comment 4 Cole Robinson 2016-04-09 20:14:06 EDT
Sorry this didn't get any follow up. qemu has changed a lot since then, this could very well be fixed. Closing as DEFERRED, if anyone can still reproduce with modern libvirt and qemu, please reopen

Note You need to log in before you can comment on or make changes to this bug.