openstack-volume team mailing list archive

[Vish Ishaya <vishvananda@xxxxxxxxx>]

I still think sorting is a good short term solution to get booting to
work again.  Beyond that we need better support for naming virtio disks.
We may have to do some guest agent / udev magic to get the names right
because it doesn't appear that udev has any way to tell which device
name it should pick for attached volumes.

-- 
You received this bug notification because you are a member of Nova
volume, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/884984

Title:
  Cannot boot from volume with 2 devices

Status in OpenStack Compute (Nova):
  Confirmed

Bug description:
  More details on:
  https://answers.launchpad.net/nova/+question/176938

  Summary:
  -------------
  Say I had 2 disks, disk1 and disk2 (represented by 2 volumes). disk1 has the root-file-system and disk2 has some data. I boot an instances using the boot-from-volumes extension, and specify the 2 disks such as disk1 should be attached to /dev/vda and disk2 to /dev/vdb. When the instance is launched it fails to boot, because it tries to find the root-filesystem on disk2 instead.

  The underlying problem is with virsh/libvirt. Boot fails because in
  the libvirt.xml file created by Openstack, disk2 (/dev/vdb) is listed
  before disk1 (/dev/vda). So, what happens is that the hypervisor
  attaches disk2 first (since its listed first in the XML). Therefore
  when these disks are attached on the guest, disk2 appears as /dev/vda
  and disk1 as /dev/vdb. Later the kernel tries to find the root
  filesystem on '/dev/vda' (because that's what is selected as the root)
  and it fails for obvious reason. I think it's a virsh bug. It should
  be smart about it and attach the devices in the right order.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/884984/+subscriptions