On Thu, Aug 30, 2012 at 8:20 AM, Nuno Fernandes <npf-mli...@eurotux.com> wrote: > Let me then start from the beginning... We are creating an opensource > virtualization solution called Nuxis (http://nuxis.com/). This solution is > based on Centos5 + some of our packages (mostly web interface and libvirt > connector (GPLv2)). We support KVM and Xen. > I our local setup we've upgraded xen to a more recent version > (xen-4.1.3-1.el5) because of some security issues. We were using xen 4.1.2.
But not security issues with Red Hat's EL5 Xen, which has backported fixes. These are security issues with the version you have already rebased ahead to prior. I.e., you're now having to provide your own sustaining engineering, and deciding between rebasing and backporting, because you're not using Red Hat Xen. [ SIDE NOTE: And in that case, you're not really tied to an EL5 platform any more either, but that's another discussion. ] > We've also upgrade some userland packages, so kernel/KABI remains in 2.6.18. > For xen packages we used the gitco repository (http://www.gitco.de/repo/) > that provides xen replacements and updates for centos5. > After the recent upgrade we are having problems starting virtual machines > (yes, i can ask in xen-users Mailling list) but i think that the problem is > in Dom0 kernel because we see logs of the type: > "xen be core: xen be core: can't open gnttab device" > And googling it points to an old Dom0 kernel. To debug this problem i tried > different new kernels (2.6.32-xen and 2.6.39uek). I know that the change in > kernel will change KABI but for debuging purposes i'm ok with that. Since you mentioned "debugging," what's the endgame here? I mean, if you're talking about backporting fixes ... ugh ... that's a lot of sustaining engineering. Or if you're going to rebase, at what point are you fighting platform changes with virtualization changes with unknown changes? > To install those kernels i've installed the oracle linux repo that points to: > # cat /etc/yum.repos.d/uek.repo ... Yeah, ignore my prior. Seems it changed as of March, although I'd still read through their FAQ on integration/support. > Best regards and thanks for any debug ideas. Well, I mean, you're just starting into figuring out boot differences. At what point does the "cost" of sustaining engineering (whether you rebase or backport), as well as the periods during this engineering when you don't have a release with mitigated security vulnerabilities, end up costing more than going with a released platform that has a large engineering team behind it that is keeping up with Xen and/or KVM, security, etc... changes? And I'm not even trying to suggest anyone (e.g., if you want to rebase XeN). I mean, I could look at what your initrd issue is if you want to provide it. But that just gets you booting. Given your errors with the dom0, I think your issues might be much deeper than you realize. -- Bryan J Smith - Professional, Technical Annoyance http://www.linkedin.com/in/bjsmith _______________________________________________ rhelv5-list mailing list rhelv5-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv5-list
