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
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