Ross S. W. Walker wrote:
Ian Jackson wrote:
Xen 3.2 is in the final stages of preparation. We (Xen
upstream) are
planning to provide binary packages for Centos 5.1, amongs others.
I've merged the patches and so on from xen-3.0.3-41.centos5.i386.rpm with a recent xen-unstable RC tip (16701:8922a1469284).
With a bit of
effort I have managed to get a set of packages which appear
to be able
to work at least in my simple `does this function at all' test.
I'm mentioning it here so that you can have a look at what I've done and comment on it. We'll probably be making official upstream rpms very soon after the Xen 3.2 release, which we hope will be
early next
week. Please send me feedback either here on-list or privately.
Most of the useful patches from 3.0.3-41.centos5 have been incorporated upstream so I just deleted those from my srpm.
There were also a few changes which I have just dropped. In particular, the RHEL5 package (and thus the Centos one too) is a bizarre frankenxen containing a forward port of the 3.0
dom0 userland
tools to the Xen 3.1 hypervisor.
In my package I have included the hypervisor in the xen-*.rpm rather than making a kernel package too. This is more in line
with practice
upstream; dom0 kernel compatibility between the 3.1 and 3.2 hypervisors is good and the new hypervisor seems to work for me with the Centos 5.1 2.6.18-53.el5xen kernel.
You can find the actual files here: http://www.chiark.greenend.org.uk/~ijackson/xen-3.2-package-pr eviews/centos5.1/
These packages should not be used for production - they're previews and I may have made elementary packaging mistakes. Xen 3.2 is still unreleased and in need of more testing.
I know I appreciate the effort you guys make to release these binaries for the different platforms.
If I had only 2 wishes they would be, 1) try to make the install mimic the distro's Xen path layout a little better, 2) provide 64-bit binaries...
Other then those two little points I have found the binaries pretty stable.
Ok, I gave it a whirl, the minor paths issue I mentioned earlier seems to be fixed here, but the 'localtime' patch needs to be backported (or forwardported in this case) as HVM clocks still only report time in UTC.
-Ross
______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.