Eugen Block wrote:
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?
pygrub should work with network-based block devices. Is your xen compute node running latest xen and libvirt, including the fix for bug#981094? Regardless, /var/log/libvirt/libxl/libxl-driver.log (and perhaps related logs in /var/log/xen/) should contain some hints as to what failed.
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?
IMO, grub.xen should always be used for PV instances in a cloud environment. pygrub mounts the image in the compute node (dom0) to extract the kernel/initrd, which unnecessarily exposes it to potential vulnerabilities due to a rouge image. Regards, Jim -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org