Bugzilla – Bug 557
Xen: OpenVZ in DomU, RHEL5 Xen kernel
Last modified: 2012-01-22 16:00:08 EST
RHEL5 kernel has Xen inside. Need to fix its compilation, check that it works. Thanks to seyko@ for some info here: http://forum.openvz.org/index.php?t=post&reply_to=12374&SQ=244d57dc8c322ce78bb5cc7b62ebe6e7&
as a final result: RHEL5 Xen kernel should be buildable from src.rpm Some patches from seyko@ will be 100% applied. Some need rework.
commited in 028stab031: openvz-Kconfig.patch openvz-tux.patch openvzelx-utsname.patch openvzelx_netback.patch
ok. rest patches will be reviewed after 028stab031. Sergey, I need your help in order to understand some of your other patches. openvzelx-tux.patch - what has it to do with tux? imho fixes compilation only due to nsproxy... openvz-vsched.patch - why? what does it fix? openvz-utsname2.patch - the same... why?
(In reply to comment #3) > openvzelx-tux.patch - what has it to do with tux? imho fixes compilation only > due to nsproxy... Yes, patch name is wrong (i think nsproxy is a tux part) > openvz-vsched.patch - why? what does it fix? vcpu_online() is not used anywhere in the kernel (there is no one implementation of this function) > openvz-utsname2.patch - the same... why? the same, it is not used anywhere
*** Bug 544 has been marked as a duplicate of this bug. ***
Evgeniy, please fix compiltion of RHEL5-OVZ Xen kernel from .spec file. check that OVZ works fine in Dom0 and in DomU.
fixed in 028stab034
(In reply to comment #7) > fixed in 028stab034 Where it is currently? Is there a inotify-reverse.patch appliend? (because main 2.6.18 do not have a modified inotify_add_watch() function... There is a stange situation with openvz-el kernel: it do not have a repository, patch is allways a commulative one, there is no simple way to find a changes in versions for this kernel. Currenly I have a problem with compiling openvz-el 028.031 for XEN using a commulative patch from you (complains about ldt_pages). And I succefully compiled a kernel with 028stab027-combined + 027-to-030.patch from repositiory. Conslusion: openvz-el need a more verbose info (like changelist with a timeorder).
(In reply to comment #7) > fixed in 028stab034 Some info abount XEN: xen-3.1.0 have a memory problems which do not allow to use it in real life Currently I going to test openvz-el-xen for a memory problems (dom0 w/o any domU). Test description: open in MidnightCommander 1.4Gb tar.bzip2 archive (press ENTER on archive name). Compiling a kernel is a plus. After some time linux-xen-3.1.0 give you a kernel dump with message abount XEN list-memory problem
(In reply to comment #9) > (In reply to comment #7) > Test description: > open in MidnightCommander 1.4Gb tar.bzip2 archive (press ENTER on archive > name). Compiling a kernel is a plus. After some time linux-xen-3.1.0 give you a > kernel dump with message abount XEN list-memory problem Abount hardware: Intel Celeron 1.7 Ghz with 512Mb of RAM (and the same kernel with the same kernel config but w/o XEN-patch-monitor do not have such problems with memory)
> Where it is currently? Is there a inotify-reverse.patch appliend? (because main > 2.6.18 do not have a modified inotify_add_watch() function... it is currently in CVS. In a couple of days I will build a kernel based on this patchset. > There is a stange situation with openvz-el kernel: it do not have a repository, > patch is allways a commulative one, there is no simple way to find a changes in > versions for this kernel. Yes, you are right, there is such problem. This is due to the fact that git is not suitable for such developement. The process looks like the following: - we have a bunch of RHEL patches and spec's where we simply add one OVZ core patch and driver related patches (since they are not OVZ modifications related) - OVZ patch is constructed from the list of patches with similar to quilt process. > Currenly I have a problem with compiling openvz-el > 028.031 for XEN using a commulative patch from you (complains about ldt_pages). > And I succefully compiled a kernel with 028stab027-combined + 027-to-030.patch > from repositiory. This is fixed by Evgeniy in 028.034. The reason is simple - in 028.028 4GB split feature was added. It is a huge patch actually which increases normal zone size up to 3gb on i686. RHEL5 dropped this feature, while we need it quite much. So I ported it. > Conslusion: openvz-el need a more verbose info (like changelist with a > timeorder). Will do one day. Will broken-out patch list suit you? Meanwhile you can simply use `interdiff -p1 patch-028stab027-core patch-028stab031-core` to see all the changes.
> Where it is currently? Is there a inotify-reverse.patch appliend? (because main > 2.6.18 do not have a modified inotify_add_watch() function... ohh, forget to answer on this. no, inotify-reverse is not applied, since this feature is required. otherwise checkpointing sometimes don't work on RHEL5 VEs since they use inotify interfaces in udev code :/ Intead, I suggest to rename functions in appropriate way - i.e. keep the original functions with the same argument set, while add new functions with additional argument which we need. we have a separate bug #552 for this issue.