There's currently no stable version of xen. This bug should depend on any thing that's holding up stabilisation of either 3.0.2 or the coming 3.0.3.
While 3.0.2 is reasonably well tested for paravirtualization (especially with Gentoo guests), I don't think HVM is ready for stablisation - bug #142969 is a good example of this. The HVM situation should improve with 3.0.3, and with positive reports from users we can proceed with stabilisation then (unless we stablise Xen with paravirtualization functionality only).
3.0.3 has been released. What's the status on this one?
3.0.4 released with 2.6.19 kernel support
Bump: 3.1 has been released
3.1 from svn://thestonertree.com/mescalito@5, pulled in via layman, has worked flawlessly here for at least 2 months in full production use. I use HVM capable CPUs, but all Gentoo paravirtualized guests.
Mike, I don't want to derogate the efforts of thestonertree.com, but if you want to help testing ebuilds for 2.6.18/.20 (and 21 to come) kernels which will go to the tree, please use those from our Xen overlay (overlays.gentoo.org, layman -a xen).
(In reply to comment #6) > Mike, I don't want to derogate the efforts of thestonertree.com, but if you > want to help testing ebuilds for 2.6.18/.20 (and 21 to come) kernels which will > go to the tree, please use those from our Xen overlay (overlays.gentoo.org, > layman -a xen). > Wow, there's an "official" gentoo Xen overlay!? mescalito (thestonertree.com) was the only place I could find with a 3.1 ebuild at the time I was looking. I'll gladly put the xen overlay on our testing/dev servers, probably this week, and give it a go.
lalala
(In reply to comment #8) > lalala > Deck the halls with stale Xen bugs, tra la la la la, la la la la How about just ping me next time, tra la la la la, la la la la Seriously though, leaving a 'lalala' comment in all of the xen bugs isn't very helpful. I already know I've been bad and neglecting xen :-( At this point I'm mainly just waiting on a Xen kernel that doesn't suck. Redhat/Fedora's recent xen kernel work is really the only hope at the moment but I haven't had a chance to test it well enough to put into the gentoo tree.
(In reply to comment #9) > (In reply to comment #8) > > lalala > > Deck the halls with stale Xen bugs, tra la la la la, la la la la > How about just ping me next time, tra la la la la, la la la la :D > Seriously though, leaving a 'lalala' comment in all of the xen bugs isn't very > helpful. I already know I've been bad and neglecting xen :-( At least I got some reaction -- that's all I meant to provoke :> > At this point I'm mainly just waiting on a Xen kernel that doesn't suck. > Redhat/Fedora's recent xen kernel work is really the only hope at the moment > but I haven't had a chance to test it well enough to put into the gentoo tree. Ok. Thanks for the explanation! What about a stabilization of Xen itself? And what about xen-sources-2.6.18 -- does it suck so much?!
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > lalala > > > > Deck the halls with stale Xen bugs, tra la la la la, la la la la > > How about just ping me next time, tra la la la la, la la la la > > :D > > > Seriously though, leaving a 'lalala' comment in all of the xen bugs isn't very > > helpful. I already know I've been bad and neglecting xen :-( > > At least I got some reaction -- that's all I meant to provoke :> > > > At this point I'm mainly just waiting on a Xen kernel that doesn't suck. > > Redhat/Fedora's recent xen kernel work is really the only hope at the moment > > but I haven't had a chance to test it well enough to put into the gentoo tree. > > Ok. Thanks for the explanation! > > What about a stabilization of Xen itself? > And what about xen-sources-2.6.18 -- does it suck so much?! > The 2.6.18 is the most reliable kernel in the tree currently but being an older kernel it has a tendency to pile up security issues. rbu has been keeping it up to date by pulling the security patches from debian's kernel since they also use 2.6.18 but I haven't tried to stabilize it because I wasn't positive we would be able to keep it up to date security wise into the future.
At this point the 2.6.18 is supported upstream with new Xen patch releases, and downstream with Security fixes. As said, I would not be able to maintain this kernel security-wise if it was not for other distributions doing the legwork. Debian will release Lenny with a new kernel in/after September. Theoretically, the old stable kernel would be supported after that, but as always the support will get more and more constrained. We should be safe at least until the end of the year, so I would say: Go for it, stable that kernel, and the 3.2.1 userspace :-) We might want to polish off some of the bugs before that. Wolfram, you are more then welcome to help, either with patches or comments. On the status of the RedHat work: They improved and extended DomU support on top off paravirt_ops, but I do not see they have gotten Dom0 anywhere near testing or production quality. My guess is that this will take more time than expected beforehand.
Update: Some Citrix programmers have been banging out dom0 support. I am hoping the majority of the patches hit 2.6.30. Perhaps xen-sources could then apply a minimal patchset on top for near-mainline kernel tracking and aid in stabilizing Xen.
Xen 4.1.0 was released yesterday and we should prepare for its stabilization. Also recent upstream kernels has full xen xupport for dom0 and domu (since 2.6.38 it has full support for xen dom0)
It seems that the current commit requires: 1. An update to the main Gentoo page regarding Xen (http://www.gentoo.org/doc/en/xen-guide.xml). It should make mention of the new toolkit xl, rather than the older xm/xend toolkit. 2. A Gentoo style init.d script for xencommons. The script is aimed at other distributions that support a bash script for their rc scripts. Take a look at the script and you'll see what I mean. This prevents OpenRC for instance from starting xencommons automatically. Other than that, it seems to run correctly. I personally haven't done any stress testing, and I don't have an elaborate configuration. Keep up the good work Alexey.
I agree with casso on this. I have been running several versions of xen without issue for several months. I just updated to 4.1.0 and ran into an issue with the scripts that I haven't been able to resolve as of yet. xend now depends on xencommons to start, but because of the way xencommons is writen you cannot currently add it as a dependency of xend nor can you simply add a depend section to xencommon, I tried a simple hack the other night after I learnt that with no success. Other than the above issue, I have not seen any issues since the update from 4.0.1 to 4.1.0. My existing xen dom0 is working and my primary domU has not been fazed in the slightest. Later today I am going to upgrade my work laptop and see if 4.1.0 fixes the issues I was having with it disabling my wireless card when starting the domU's. It was never clear if that was a gentoo or xen issue as I never got any answers on the forums I searched/posted.
Created attachment 268615 [details] Replacement init.d for xencommons I've attached a quick port of xencommons over to gentoo's format. I haven't given this thorough testing so it might need some tweaking, but it works for me. (In reply to comment #14) > Also recent upstream kernels has full xen xupport for dom0 and domu (since > 2.6.38 it has full support for xen dom0) That's incorrect as far as I'm aware, 2.6.38 has limited backend support but it's still missing some significant components like networking support. See this page for more details & a roadmap: http://wiki.xensource.com/xenwiki/XenParavirtOps
Created attachment 270595 [details] edit xencommons script for shutdown daemon
(In reply to comment #18) > Created attachment 270595 [details] > edit xencommons script for shutdown daemon I tried xencommons port and i found some error when stop daemon, the stop was not complete. I edit xencommons with regular process to stop two daemon ( xenstored and xenconsoled ) and now i put my file here. I hope with this help someone
