On Tue, 1 Nov 2011, Vishvananda Ishaya wrote: > Sounds like we can work around this pretty easily by sorting the disks before > we pass them into the xml template.
The long term solution here is not to load the kernel and the ramdisk outside the image, but rather let grub load it with root=LABEL=xxxx or root=UUID=xxxx . If you boot one of the full disk Ubuntu image (-disk1.img) files at https://cloud-images.ubuntu.com/releases/oneiric/release/ or https://cloud-images.ubuntu.com/server/natty/current/ , then you wont have the problem. You'll also be able to 'apt-get update && apt-get dist-upgrade && reboot' and get a new kernel. That is not possible with the hypervisor doing the kernel and ramdisk loading. This is assuming that in the multiple-disks-attached scenario, the *real* root disk (the one with the bootloader on it) is found by bios. static device names were deprecated several years ago by all linux distributions. Lets move towards using the better solution. > > Vish > > On Nov 1, 2011, at 9:52 AM, Gaurav Gupta wrote: > > > Hi all, I asked a question on Launchpad. but haven't heard back anything > > yet. Trying this forum to see if someone has any idea how to resolve this > > issue: > > https://answers.launchpad.net/nova/+question/176938 > > > > To summarize: > > ---------------------- > > > > 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, > > which causes the boot failure. Later the kernel tries to find the root > > filesystem on '/dev/vda' (because thats' 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. > > _______________________________________________ _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
