Bug 161083

Summary:	Wrong version number. Too old version.
Product:	[Fedora] Fedora	Reporter:	Nils Toedtmann <bugzilla.redhat.com>
Component:	xen	Assignee:	Rik van Riel <riel>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	low	Docs Contact:
Priority:	medium
Version:	4
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-06-20 21:07:42 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Nils Toedtmann 2005-06-20 14:47:27 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4

Description of problem:
Version is "3.0-devel" (also referenced as "unstable") from 2005-04-24, not 2.x from 2005-05-25 or 2005-05-30 as the rpm version suggests.

Version-Release number of selected component (if applicable):
xen-2-20050522, xen-2-20050530

How reproducible:
Always

Steps to Reproduce:
rpm -q xen
xm dmesg
head -1 /usr/share/doc/xen-2/ChangeLog
rpm -q --changelog xen

Actual Results:  rpm -q xen: 
  xen-2-20050522
xm dmesg:
  Xen version 3.0-devel
  Latest ChangeSet: information unavailable
head -1 /usr/share/doc/xen-2/ChangeLog: 
  ChangeSet, 2005-04-23 17:01:19+01:00, kaf24.cam.ac.uk

Expected Results:  rpm -q xen: 
  xen-2.99.20050424-4
xm dmesg:
  Xen version 3.0-devel
  Latest ChangeSet: 2005/04/23 17:01:19 1.1377


Additional info:

Disclaimer: I really appreciate the work the fedora team has done to bring xen to the masses. My suggestions shall just help make it easier to use xen and to experiment with it. They are meant as proposals, not as rebukes ;-)

* The wrong version is misleading, as the xen api has changed from 2.0.X to 3.0(-devel). Neither it is a xen-2 nor it is from 20050522. You could even upgrade xen-2-20050522 to xen-2.0.6! The FC4 rpm should be named "xen-3.0pre.$DATE-$REL" or "xen.2.99.$DATE-$REL" or similar. See the ntp rpm versioning as example.

* xen-unstable from 2005-04-24 is rather old. Since then, many bugs have been fixed and some features are added (Eg. xend now uses unix sockets instead of tcp sockets for VM consoles). BK changeset numbers have grown from 1.1377 to 1.1724. Recent domain-U kernels won't boot. If you decide to use "unstable" instead of "stable" (2.0.x) you should stick with development.

* The xen kernel image (/boot/xen.gz) is much like a linux kernel image. Like the latter, it should have a version (/boot/xen-2-20050522.gz) and it should have its own rpm package which can be multiple installed. Eg, name the two packages "xen-kernel"+"xen", or "xen"+"xen-tools".

* As i am in: i'd suggest splitting the kernel-xenU package into kernel-xenU (only the kernel image, to be installed in dom0) and kernel-xeU-modules (all the other stuff like modules, System.map, ..., to be installed in domU).

Comment 1 Michael Paesold 2005-06-20 21:00:45 UTC

+1 from me for this request.

Comment 2 Rik van Riel 2005-06-20 21:07:42 UTC

I agree with the verion number issue, but it's too late to fix that for FC4.

As for upgrading to a new Xen snapshot, that also requires changing the kernel,
since the handling of ACPI moved from Xen into domain 0.  I tried upgrading
rawhide to a newer Xen (before FC4), but that version did not boot on my test
system, so I decided to stay with the version from FC4 test 3.

I agree on the /boot/xen-<version>.gz idea in principle, but in practice it
turns out that things break far too often if the xen.gz does not match the
installed utilities - that interface is also still in flux.

IMHO the proper fix for the xenU kernel living outside of the domain's
filesystem is to have a Xen bootloader - which is available upstream and will be
in newer Xen RPMs for rawhide.  That way the kernel can just live inside the domU.

I will upgrade Xen in rawhide, once Xensource has a Xenolinux for 2.6.12.