Hi Thomas, thanks for the quick response! I ran some tests to verify your suggestion. Please notice that we are using Ceph as storage backend, that's why I had to run the tests for SLE11 twice. Here is a summary of my tests: cirrOS: w/o changes in driver.py: works w/ changes in driver.py: works w/ glance kernel-id: fails SLE12: w/o changes in driver.py: fails w/ changes in driver.py: works w/ glance kernel-id: works SLE11 (Image in RBD pool): w/o changes in driver.py: fails w/ changes in driver.py: works w/ glance kernel-id: works SLE11 (Image in local fs): w/o changes in driver.py: works w/ changes in driver.py: works w/ glance kernel-id: works The SLE12 image did not boot without my patch, I updated the image property with the grub.xen uuid as suggested, that worked quite well. I tried the same with a cirros image, it did not boot with the kernel-id property. It's just an image for testing purposes, but extremely helpful for quick tests, so I need it to work, too. Then I tested a SLE11 image to see if older images are still working. Without modifications in driver.py or the glance image, the VM wouldn't boot. Is it possible that pygrub is not capable of working with network backed images? Because when I switched back to local file system, the VM boots without any problems, also without any changes. It worked both with a kernel-id and with a code change for the rbd backed image. So in general, your suggestion works. But regarding the maintenance of a cloud, it seems not very handy. If I understand correctly, in case of an grub update I would have to upload a new grub image to glance, then replace the reference to that old kernel-id with the newly updloaded kernel-id. That doesn't sound very useful, to be honest. Although the code change is very practical for me, I have to admit that it's not a general solution as it doesn't take into account any system relevant information besides the virt_type. But let's say you would build a real patch that contains some information on how to choose the correct bootloader, wouldn't that be more practical? Another question comes to my mind: is there any reason to stick with pygrub instead of using grub.xen? To me it seems that grub.xen is more powerful (e.g. booting rbd images), and if IIRC that's what SUSE did in the python-nova package, at least in the patch I received within the service request mentioned before. Is there any reason I'm not seeing right now to not use grub.xen as default? Regards, Eugen Zitat von Thomas Bechtold <tbechtold@suse.com>:
Hi Eugen,
On Mon, May 30, 2016 at 09:21:36AM +0200, Eugen Block wrote:
Hi all,
I would like to follow up on an issue I had a couple of months ago with nova libvirt. During my tests with SUSE Cloud 5 there was a problem launching Xen VMs, the wrong bootloader was selected for images with version >= SLE12. There was a service request for that issue, ServiceRequestID 10969858451. The proposed fix was this piece of code in python-nova/virt/libvirt/driver:
---cut here--- + if CONF.libvirt.virt_type == 'xen': + guest.os_kernel = '/usr/lib/grub2/x86_64-xen/grub.xen' ---cut here---
This worked just fine, but now that I use Openstack (Mitaka) Cloud, I run into the same issue. So everytime I update my packages, I first have to patch the driver.py on my compute nodes.
You don't need this patch. Install the grub2-xen package and create a glance image with the kernel from the package (/usr/lib/grub2/x86_64-xen/grub.xen ). Then for your Xen image, add the kernel-uuid from the previously created image (glance image-update grub-xen-uuid --property kernel_id=xen-image-uuid ). Now the image should boot with the correct kernel.
Best,
Tom
-- Eugen Block voice : +49-40-559 51 75 NDE Netzdesign und -entwicklung AG fax : +49-40-559 51 77 Postfach 61 03 15 D-22423 Hamburg e-mail : eblock@nde.ag Vorsitzende des Aufsichtsrates: Angelika Mozdzen Sitz und Registergericht: Hamburg, HRB 90934 Vorstand: Jens-U. Mozdzen USt-IdNr. DE 814 013 983 -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org