https://bugzilla.novell.com/show_bug.cgi?id=851338 https://bugzilla.novell.com/show_bug.cgi?id=851338#c Marc Michele changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P2 - High Severity|Major |Critical -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=851338 https://bugzilla.novell.com/show_bug.cgi?id=851338#c3 Mark Starikov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mr.mark.starikov@gmail.com --- Comment #3 from Mark Starikov 2013-12-11 00:38:59 UTC --- Dear SUSE engineering, Attaching xc domain builder log of starting openSUSE 13.1 x64 kernel-3.11.6-4-xen and openSUSE12.3 x64 kernel-3.7.10-1.16-xen. it seems that kernel-3.11 is unziped, but the xc_dom_release call comes way too quickly(straight after FEATURES parsing of the elf). Interesting part is that 12.3 has this features: writable_page_tables writable_descriptor_tables auto_translated_physmap supervisor_mode_kernel While 13.3 has following: writable_page_tables writable_descriptor_tables auto_translated_physmap supervisor_mode_kernel dom0 Does it assume privileged domain by default? Haven't had a chance to look through the release notes for changes yet, but seems some incompatibility introduced there... Thanks in advace. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=851338 https://bugzilla.novell.com/show_bug.cgi?id=851338#c5 --- Comment #5 from Mark Starikov 2013-12-11 00:41:17 UTC --- Created an attachment (id=571211) --> (http://bugzilla.novell.com/attachment.cgi?id=571211) xen dmesg from XenServer 6.2 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=851338 https://bugzilla.novell.com/show_bug.cgi?id=851338#c7 --- Comment #7 from Mark Starikov 2013-12-11 05:05:35 UTC --- So, I've recompiled the kernel-xen with single change to .config (CONFIG_XEN_COMPAT flags set to 0x040100 like in 12.3) and XenServer was able to boot it up. Looks like that was the cause of the xc builder exiting prematurely. This is somewhat sad, since openSUSE always was a distro that ran very smoothly on XenServer, and it's difficult to say if the next release of XenServer will cross over to Xen 4.2. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=851338 https://bugzilla.novell.com/show_bug.cgi?id=851338#c11 Konrad Scherer changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |konrad.scherer@windriver.co | |m --- Comment #11 from Konrad Scherer 2013-12-18 15:48:24 UTC --- I can confirm this bug with Xen 4.1 on Debian Wheezy. Unfortunately Xen 4.2+ is part of Debian testing. I would prefer to stay with Debian Wheezy. I was able to work around the installation and running of 13.1 in Xen 4.1 by using the 12.3 kernel-xen package and 12.3 installer. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=851338 https://bugzilla.novell.com/show_bug.cgi?id=851338#c15 --- Comment #15 from Nick Couchman 2014-02-22 21:07:11 UTC --- I also have this issue. Any update on this? This is kind of a big deal, and seems like it shouldn't be too difficult to fix - recompile kernel with correct options and respin the ISO and/or network repos. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=851338 https://bugzilla.novell.com/show_bug.cgi?id=851338#c19 Nick Couchman changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|jdouglas@suse.com | --- Comment #19 from Nick Couchman 2014-02-26 15:39:58 UTC --- Comment 6 provides the information needed to fix the bug - kernel in openSuSE 13.1 needs to be compiled with CONFIG_XEN_COMPAT_040100_AND_LATER=y. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=851338 https://bugzilla.novell.com/show_bug.cgi?id=851338#c Jason Douglas changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|jdouglas@suse.com |jbeulich@suse.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=851338 https://bugzilla.novell.com/show_bug.cgi?id=851338#c26 Andrew Daugherity changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adaugherity@tamu.edu --- Comment #26 from Andrew Daugherity 2014-05-14 18:31:51 UTC --- FYI, this also affects SLES 11 SP1 Xen hosts (and maybe SLES 10 too?). It fails with: Failed to start the VM. Error: (11, 'Resource temporarily unavailable') openSUSE 12.3 and earlier VMs run fine. I realize SP1 is now out of support but we are stuck on it for now pending a kernel bugfix for SP2/SP3 (for which I have an SR open). Applying this fix should also let 13.1 VMs run on SLES 11 SP1. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=851338 https://bugzilla.novell.com/show_bug.cgi?id=851338#c28 --- Comment #28 from Fabian Vogt 2014-05-14 19:23:43 UTC --- (In reply to comment #27)

(In reply to comment #26)

...

FYI, this also affects SLES 11 SP1 Xen hosts (and maybe SLES 10 too?). It fails with: Failed to start the VM. Error: (11, 'Resource temporarily unavailable')

openSUSE 12.3 and earlier VMs run fine.

I realize SP1 is now out of support but we are stuck on it for now pending a kernel bugfix for SP2/SP3 (for which I have an SR open). Applying this fix should also let 13.1 VMs run on SLES 11 SP1.

The issue in this bug with kernel compatibility level should not effect SLES 11 SP1/SP2 which have CONFIG_XEN_COMPAT_030200 and also SLES 11 SP3 which has CONFIG_XEN_COMPAT_040100. In other words, XenServer 6.2 should be able to load them without problem (see also comments #6 and #7).

He's referring to SLES as host, not guest. AFAIK SLES 11 SP1 uses Xen 4.0.0 so it's unable to boot 13.1. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=851338 https://bugzilla.novell.com/show_bug.cgi?id=851338#c30 --- Comment #30 from Nick Couchman 2014-05-14 20:17:02 UTC --- (In reply to comment #29)

(In reply to comment #28)

...

He's referring to SLES as host, not guest. AFAIK SLES 11 SP1 uses Xen 4.0.0 so it's unable to boot 13.1.

You are right. I should have read it more carefully. There is not much that can be done for any OS that has already shipped. The are no plans to re-master any media (including os13.1), so we are left with the xen kernel compat level already found in os13.1.

That seems like a poor choice - I've been waiting for this bug to be fixed to replace my openSuSE 12.1 VMs with openSuSE 13.1. When is 13.2 due out? Hopefully it won't suffer from the same bug? I'd beg that you reconsider. If you won't reconsider, then please do the following two things: 1) At least fix it and provide an updated kernel package. This way we could install the VM on whatever host (SLES11, XenServer, etc.) in HVM mode, then update to the fixed package and switch to PV mode. At least, I'm guessing (hoping) it only affects PV mode?! 2) Provide instructions for manually replacing the kernel and initrd in the network install tree with a fixed version - I'm sure there are many (including myself) who mirror (or would consider mirroring) the openSuSE 13.1 source for internal use and would gladly go do this little bit of legwork in the mirrored repos we maintain in order to make this work. Respectfully, Nick -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=851338 https://bugzilla.novell.com/show_bug.cgi?id=851338#c32 --- Comment #32 from Nick Couchman 2014-05-15 15:47:29 UTC --- (In reply to comment #31)

(In reply to comment #30)

...

That seems like a poor choice - I've been waiting for this bug to be fixed to replace my openSuSE 12.1 VMs with openSuSE 13.1. When is 13.2 due out? Hopefully it won't suffer from the same bug?

As it stands right now it will. The problem is that so far no-one has come up with a workable replacement scheme for determining the desired compatibility level, and hence we're going to stick to the "compatible with the previous openSUSE release" one.

Hmmm...guess I won't be using much openSuSE in the future.

Schemes looked at but not considered workable/reasonable: - compatible with everything (i.e. back to 3.0.2) - compatible with an ad hoc set of host distros

A scheme that I would personally consider workable, but that wouldn't help you here would be to tie compatibility to versions being actively maintained by xen.org - 4.1.x has been out of support for quite a while...

The main requirements for a scheme to be workable are - not vendor centric - not locking us into compatibility with an old version indefinitely - clear up front determination of when the compatibility level can be raised (this in particular means independence of other vendors' release schedules)

This is a difficult set of criteria to meet. Despite the criteria of "not vendor-centric," and "independence of vendors' release schedules," it pays to look at what's being used by various Xen-based hosts out on the market. Software companies producing commercial software (costing $$) routinely look at other vendors, their current offerings, and their release roadmaps to make their software compatible with those other vendors' products. Why should openSuSE behave any differently? Citrix XenServer is one of the more well-known Xen-based systems out there, and their latest version of XenServer (6.2) uses Xen 4.1. Why not just do compatibility for the major version - e.g. Xen 4.x (4.0 - 4.4)? Or what's the harm in making it compatible with everything? It's been a while since I looked at the documentation for the compatibility flags, but is there something lost in setting compatibility for everything from 3.0 forward? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=851338 https://bugzilla.novell.com/show_bug.cgi?id=851338#c34 --- Comment #34 from Jan Beulich 2014-05-16 08:18:19 UTC --- (In reply to comment #32)

It's been a while since I looked at the documentation for the compatibility flags, but is there something lost in setting compatibility for everything from 3.0 forward?

Yes - there a page table handling quirks needed for very old hypervisor versions which we better avoid, making the code more robust. (In reply to comment #33)

What's wrong with using the same compatibility settings as openSUSE 12.3 (Xen 4.1 compat)? This appears to work in most Xen hosts. Is there really anything extra to maintain beyond setting the line in the kernel config?

Did you read #31 at all? What would be the basis to have the setting that way? And when would be the time to bump it? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=851338 https://bugzilla.novell.com/show_bug.cgi?id=851338#c36 --- Comment #36 from Jan Beulich 2014-05-16 09:02:21 UTC --- (In reply to comment #35)

Could "do like other distros did" be the compartibility policy ? CentOS works with XenServer 6.2, Ubuntu works, Debian works, OS 13.1 doesn't work. Sad.

Any pv-ops based one among them (the only one I'm uncertain about is CentOS, not the least because you don't say which version) means not comparing apples with apples: pv-ops doesn't have any way to limit compatibility. I.e. the equivalent would be for us to make all openSUSE versions 4.0 compatible, without ever having a way to bump this. So yes, this could be considered an option (violating the "not locking us into compatibility with an old version indefinitely" requirement set forth earlier). Yet there's one thing that would need to be addressed: Who's going to test current and future openSUSE versions on 4.0 Xen? Without that, there's not much point in setting such a compatibility level. (And to be honest, over time I expect pv-ops to [inadvertently] violate that compatibility too, simply because no-one would notice that some new addition doesn't work anymore with old enough hypervisors.) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=851338 https://bugzilla.novell.com/show_bug.cgi?id=851338#c38 --- Comment #38 from Jan Beulich 2014-05-16 10:15:37 UTC --- IMO such validation ought to happen _before_ a release, not by fixing bugs afterwards. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=851338 https://bugzilla.novell.com/show_bug.cgi?id=851338#c40 --- Comment #40 from Nick Couchman 2014-05-16 15:52:38 UTC --- (In reply to comment #34)

(In reply to comment #32)

...

It's been a while since I looked at the documentation for the compatibility flags, but is there something lost in setting compatibility for everything from 3.0 forward?

Yes - there a page table handling quirks needed for very old hypervisor versions which we better avoid, making the code more robust.

Okay, so what about my suggestion to do compatibility to the top-level Xen version (4.x)? Or provide pv-ops in the default kernel, and then a separate kernel-xen that is not pv-ops and does not contain all of the backward-compatibility? Or provide a kernel-xen-compat package that has a kernel that is specifically backward-compatible? Jan, we're not trying to beat up on you guys, and we're not unsympathetic to your challenge of figuring out how to move the code along when it needs to be moved. We're trying to compromise, to find a way to continue to run openSuSE distributions on popular, well-known hypervisor platforms like XenServer. As a few other folks have pointed out, several other distributions have figured out how to do this - including RHEL/CentOS, which doesn't even provide an out-of-the-box way to run as a Xen host, it's strictly developed as a Xen guest O/S. I realize that RHEL and CentOS are using older kernels, etc., but even Fedora 20 will run correctly as a PV guest on XenServer. Others have stated that Ubuntu works fine. I'm not familiar with their development practices or how they arrived at the decision of what compatibility to enable, but they did, and, as a result, a wider range of users is able to run Fedora and Ubuntu on many different host platforms, including the latest XenServer. As I stated before, at this point I'd be happy to compromise for some sort of instructions (on the openSuSE Wiki, perhaps) about how to recompile a kernel and replace the install source kernel/initrd images with backward-compatible ones. We're looking for something, some way to continue to use openSuSE in our environments. The community here, in particular the folks on this bug, have provided many possible solutions. None of them seem to be palatable to you, and I respect that you have good reason for that, but can you make us a counter-offer that doesn't involve something like "Replace all of your existing XenServer infrastructure with Xen-based host XYZ?" -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=851338 https://bugzilla.novell.com/show_bug.cgi?id=851338#c42 --- Comment #42 from Nick Couchman 2014-05-16 16:07:56 UTC ---

...

Or provide a kernel-xen-compat package that has a kernel that is specifically backward-compatible?

That we already have - kernel-ec2. Just that it comes without any PCI pass-through support.

Okay, I'll give that a try. At this point I don't need any PCI pass-through support for Linux guests, and would gladly settle for that.

...

I respect that you have good reason for that, but can you make us a counter-offer that doesn't involve something like "Replace all of your existing XenServer infrastructure with Xen-based host XYZ?"

You may not like to hear this, but - use SLES instead of openSUSE?

I do purchase and run SLES in many instances, but there are times when I need the newer, cutting-edge packages, rather than the stable ones. Also, the GUI options available in openSuSE are much better and much more friendly than SLES, so when I'm looking at using it for a sort of Linux Terminal Server or Linux Remote Desktop, I want better user experience. I know some of this can be changed by adding repos to SLES, upgrading major package groups, etc., but that kind of defeats the point of purchasing SLES as a stable platform. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=851338 https://bugzilla.novell.com/show_bug.cgi?id=851338#c44 --- Comment #44 from Konrad Scherer 2014-05-16 17:21:57 UTC --- Unfortunately this workaround does not work for me as I require PCI passthrough. My current workaround is to install the 12.3 kernel. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=851338 https://bugzilla.novell.com/show_bug.cgi?id=851338#c47 --- Comment #47 from Nick Couchman 2014-05-18 20:48:22 UTC --- (In reply to comment #46)

Gentlemen,

Not really sure why so much fuzz about recompiling kernel - this is a 30 minutes job.

Scale? Management? Future versions? Those things come to mind off the top of my head. Sure, recompiling with one option different is a pretty trivial task. Doing it for several hundred virtual machines across different XenServer pools becomes less trivial. Doing that every time the kernel package gets upgraded (and remembering that it has to be done after you run that kernel update but before you reboot those VMs) is now a significant challenge. One of the reasons we like openSuSE and use it as one of our standard distributions is because things just work - it isn't that we don't like to tinker, or don't know how to, it's that we don't always have the time to.

In either case, I've tried putting together a wiki page to help with recompiling kernel and other nifty tricks: https://en.opensuse.org/SDB:How_to_install_openSUSE_13.1_as_PV_guest_on_XenS...

This is my first attempt to write a public wiki page, so any feedback is more than welcome.

HTH

Thanks for the info...maybe I'll add my steps for installing EC2 kernel and using that for those who are interested. Maybe we could also get a kernel-xen-compat package created in one of the community repos and maintain backward compatibility from there, that way people could just add that repo and install that package. Then SuSE could continue to push the main kernel-xen package forward in terms of compatibility, but those of us who require running it on some of the hosts that take a little longer to catch up would still have options. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=851338 https://bugzilla.novell.com/show_bug.cgi?id=851338#c49 --- Comment #49 from Nick Couchman 2014-05-19 05:10:02 UTC ---

I completely understand, and I do apologize for the way that comment came out - I wasn't trying to imply that users are incapable of recompiling kernel, just wanted to point out that this thread was leaning more towards arguing why compatibility level should have stayed at 4.1 rather than discussing what can be done about this whole situation.

I certainly have more than an ideological argument here - my question is very practical in nature. I do understand the side of leaving behind legacy and pushing compatibility forward, as longs as there's good reason to do so (performance gains, bugs, etc.), but I think it needs to be balanced with making it usable for a wide variety of folks.

That'd be great. I'm not sure what's the permissions are on the wiki, so if you cannot edit it yourself, just email me instructions and I'll make sure to add it to the article.

I'll try to check in the next couple of days and see what I can do.

...

Maybe we could also get a kernel-xen-compat package created...

I think this would be the best way to go about it. I'm thinking hosted build service that checks for kernel updates daily, recompiles and pushes it to the repo. That way we probably can come up with a way to boot installtion using EC2 kernel -> add repo with compat kernel -> switch version right during installation and restore regular workflow.

Maybe so...I think the biggest challenge here is building an install initrd image that has the right kernel version that will boot on XenServer but is also an install initrd. That's where I can use some help. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=851338 https://bugzilla.novell.com/show_bug.cgi?id=851338#c51 --- Comment #51 from Mark Starikov 2014-05-20 03:28:07 UTC --- (In reply to comment #50)

I edited the Wiki and added the steps as "Method 3" for using the EC2 kernel. I will note that this has some of the same challenges as recompiling a kernel - that scale, time, management, etc., factor in to having to go through these steps to install each VM. However, once they are up and running, updates become easy - just update the EC2 kernel and reboot.

I still think that having a kernel-xen-compat package in the Kernel:opensuse-13.1 repo is probably the best way to go - that way the kernel could include PCI passthrough (and perhaps some other things missing from the EC2 kernel) but would have some backward compatibility set.

Thanks Nick for adding that info - I'll see if it's possible to extract EC2 kernel directly from installation ISO. That way you can skip the whole kernel rebuilding process and install it straight away. Then you would only compile kernel if you need support for PCI passthrough etc. Yesterday, alpha release of the next XenServer version has been made available for testing: http://xenserver.org/blog/entry/xenserver-next-alpha-available-for-download.... It's impossibly to say for sure if official release will be of the same configuration as alpha(e.g. Dom0 with 64-bit kernel 3.x on Xen 4.4), but I get a feeling that this puts to rest my original doubts of if it will get across Xen 4.1 or not. If someone still interested in creating community repository for kernel back compatible with Xen 4.1, I think this would be a good place to start: http://en.opensuse.org/openSUSE:Build_Service_Tutorial , but where I stand, a number of ways to deal with this problem are available and documented. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=851338 https://bugzilla.novell.com/show_bug.cgi?id=851338#c53 --- Comment #53 from Mark Starikov 2014-05-23 07:44:45 UTC --- (In reply to comment #52)

Compatibility level set back to 4.1 on both 13.1 and Factory (master), without any plan to ever touch this again (as leaving it at where it is now is the apparently only consistent policy going forward). We can only hope that this is not going to cause problems at some point; ideally we'd see the kernel switch to pv-ops anyway rather sooner than later.

Hi Jan, Could you please elaborate on how this will take effect? specifically: - Will there be an ISO respin or kernel will be in specific repos? - Will this change take effect only from particular kernel version(e.g current at the time of decision) or kernels will inherit those changes all the way back to 3.11.6-4? Thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=851338 https://bugzilla.novell.com/show_bug.cgi?id=851338#c Swamp Workflow Management changed: What |Removed |Added ---------------------------------------------------------------------------- Status Whiteboard| |obs:running:2876:important -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=851338 https://bugzilla.novell.com/show_bug.cgi?id=851338#c56 --- Comment #56 from Nick Couchman 2014-06-26 18:09:04 UTC --- (In reply to comment #53)

(In reply to comment #52)

...

Compatibility level set back to 4.1 on both 13.1 and Factory (master), without any plan to ever touch this again (as leaving it at where it is now is the apparently only consistent policy going forward). We can only hope that this is not going to cause problems at some point; ideally we'd see the kernel switch to pv-ops anyway rather sooner than later.

Hi Jan,

Could you please elaborate on how this will take effect? specifically: - Will there be an ISO respin or kernel will be in specific repos? - Will this change take effect only from particular kernel version(e.g current at the time of decision) or kernels will inherit those changes all the way back to 3.11.6-4?

Thanks.

Basically what you'll need to do for XEN versions affected by this is install openSuSE 13.1 in HVM mode, then update to the working kernel-xen package, then convert to PV. Converting to PV is pretty easy, both in XenServer and in the plain XEN (e.g. SLES) systems - a quick Google search should help you out. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.