Please backport Xen 3.3 from Intrepid

Bug #260998 reported by agent 8131
36
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Hardy Backports
Fix Released
Wishlist
Unassigned

Bug Description

This is potentially a more time consuming backport but with Xen 3.3 being a huge improvement over 3.2 it would definitely help Ubuntu server market share to have Xen 3.3 available in Ubuntu 8.04. Many server operators will want Xen 3.3 but will want to continue running the LTS release rather than upgrade to Intrepid. The source package that needs backporting is xen-3.3:

http://packages.ubuntu.com/source/intrepid/xen-3.3

Revision history for this message
Michael Casadevall (mcasadevall) wrote :

Xen requires that we backport the kernel itself, which is outside the scope of the backports project. Marking this wontfix as the amount of effort is tremendous unless a backport developer disagrees.

Changed in hardy-backports:
importance: Undecided → Wishlist
status: New → Won't Fix
Revision history for this message
agent 8131 (agent-8131) wrote :

Perhaps you could document why this is the case. Currently with Debian one can use the Xen 3.2 backport with the Xen dom0 kernel in Etch. I'm not sure why this wouldn't be the same case with Hardy. Is there some sort of incompatibility that has been introduced in Xen 3.3 that prevents it from working with the 2.6.24 Xen kernels in Ubuntu 8.04?

I attempted to find information about this issue and yet came across something else that was curious: there does not seem to be a Xen Dom0 kernel in Ubuntu 8.10. Is Ubuntu abandoning Xen dom0 support like Debian is in Lenny? If so I suspect there will be a loss of market share to CentOS.

Revision history for this message
Michael Casadevall (mcasadevall) wrote :

Xen requires a special kernel to support booting. While these kernels are built from the intrepid source package, it creates difficulties in testing backports and such since not only are you adding the hypervisor, but an updated kernel to match the changes made by xen in the kernel source.

Backports are supposed to be relatively non-disruptive. By introducing a Xen kernel update through backports, you encounter issues which may only happen on specific hardware, as well as issues which may occur while the computer is booting and so forth. This undermines the philosophyof backporters.

Looking at backports.org, it appears they only backported the hypervisor and not the kernel. This may be an acceptable solution, but I have no means which to test Xen dom0 support, nor do I think backporting the hypervisor alone given the possibility of bugs due to the old dom0 kernels in hardy and the newer hypervisors. I'm leaving this WONTFIX, but any other backports developer should reopen this if they feel they disagree with me.

Revision history for this message
agent 8131 (agent-8131) wrote :

Just to clarify, my request was for a backport of the packages built from the xen-3.3 source package, not for any dom0 capable kernels. I have no doubt that plenty of individuals will be willing to assist testing such a backport. My intention is to move to Xen 3.3 as soon as possible due to the massive improvements it provides. If that means using the source directly so be it, but if I can find a community willing to promote and support Xen all the better. I expect that everyone who chooses to use backports is aware that those packages are neither as well tested nor as supported as packages from the main repositories. I've got several Xen test servers and I may just backport the packages myself if I decide to stick with Ubuntu on those servers. Of course if both the Debian and Ubuntu communities do not feel strongly about supporting Xen then perhaps I should be looking elsewhere for that support. It may be wise to follow the Debian backports and see if they are able to successfully backport Xen 3.3 for use with the 2.6.18 linux kernel in Etch. If so it may signal that a backport would be worthwhile for Ubuntu backporters to pursue. Alternatively, It may be wise to take the lead and backport the packages and let the users who wish to do so test them. I fully expect that if there are kernel incompatibilities or source code changes required for the backport that the backport will be dropped. At least it will have been tried and people will know what the status of Xen 3.3 in Ubuntu 8.04 is.

Revision history for this message
Rusty Burchfield (gicodewarrior) wrote :

It would appear that the addition of the xen 3.3 hypervisor would not collide with any existing users installations.

$ apt-cache search xen-hypervisor
xen-hypervisor-3.1 - The Xen Hypervisor for i386, amd64 amd lpia
xen-hypervisor-3.2 - The Xen Hypervisor for i386 and amd64.

Doesn't this reduce the worry about breaking existing functionality?

~Rusty

Revision history for this message
Michael Casadevall (mcasadevall) wrote :

Given that this doesn't seem to conflict with the kernel as I thought, remarking to New, and testing now.

Changed in hardy-backports:
status: Won't Fix → New
Revision history for this message
Michael Casadevall (mcasadevall) wrote :

Marking this one OK to Backport.

Tested: 3.3.0-1ubuntu5

Package has no rdepends (libxen is statically built, so there are no rdepends). Builds and installs just fine, but I can't test that it runs properly since I don't have a dom0 kernel. The utilities themselves appear to work however, I simply can't test the hypervisor itself.

Changed in hardy-backports:
status: New → Triaged
Revision history for this message
agent 8131 (agent-8131) wrote :

Are these packages available for testing or should I just wait until they hit the backports repository?

Revision history for this message
Michael Casadevall (mcasadevall) wrote :

Just wait until it hits the backports repo. We're dealing with a slight backlog of backports at the moment.

Revision history for this message
Jason Kendall (coolacid) wrote :

Anyone have updates on when this will be pushed to repo?

Revision history for this message
Michael Casadevall (mcasadevall) wrote :

Generally, speaking, we need an official MOTU backporter to confirm it. Currently, there are only two active, so things have been moving kinda slow. I'll poke one of them tonight into acking this.

Revision history for this message
Adam Guthrie (therigu) wrote :

I built this on Hardy using prevu and also installed it. Both worked fine for me.

Revision history for this message
Scott Kitterman (kitterman) wrote :

Ack from ubuntu-backporters.

Changed in hardy-backports:
status: Triaged → In Progress
Revision history for this message
Martin Pitt (pitti) wrote :

 * Trying to backport xen-3.3...
  - <xen-3.3_3.3.0-1ubuntu7.dsc: downloading from librarian>
  - <xen-3.3_3.3.0-1ubuntu7.diff.gz: downloading from librarian>
  - <xen-3.3_3.3.0.orig.tar.gz: downloading from librarian>
I: Extracting xen-3.3_3.3.0-1ubuntu7.dsc ... done.

Changed in hardy-backports:
status: In Progress → Fix Released
Revision history for this message
Boris Derzhavets (bderzhavets) wrote :

How to make backports repository available on Hardy
( to become search able for Synaptic Manager ) ?

Revision history for this message
Boris Derzhavets (bderzhavets) wrote :

Done. Nothing new about xen

Revision history for this message
Boris Derzhavets (bderzhavets) wrote :

Index of /ubuntu/dists/hardy-backports
[ICO] Name Last modified Size
[DIR] Parent Directory -
[ ] Contents-amd64.gz 26-Oct-2008 04:35 907K
[ ] Contents-i386.gz 26-Oct-2008 04:44 907K

Revision history for this message
Scott Kitterman (kitterman) wrote :

This is because xen-3.3 is a new package for Hardy and so it needs a manual review by the archive admins. This is normal.

https://launchpad.net/ubuntu/hardy/+source/xen-3.3/3.3.0-1ubuntu7~hardy1

shows the status. It won't be available until it no longer says 'NEW' in the builds section.

Revision history for this message
Boris Derzhavets (bderzhavets) wrote :
Revision history for this message
Boris Derzhavets (bderzhavets) wrote :
Download full text (4.0 KiB)

# apt-get install prevu
# DISTRO=hardy prevu-init
# wget https://launchpad.net/ubuntu/hardy/+source/xen-3.3/3.3.0-1ubuntu7~hardy1/+files/xen-3.3_3.3.0-1ubuntu7~hardy1.diff.gz
# wget https://launchpad.net/ubuntu/hardy/+source/xen-3.3/3.3.0-1ubuntu7~hardy1/+files/xen-3.3_3.3.0.orig.tar.gz
# wget https://launchpad.net/ubuntu/hardy/+source/xen-3.3/3.3.0-1ubuntu7~hardy1/+files/xen-3.3_3.3.0-1ubuntu7~hardy1.dsc
Now build :-
# /usr/bin/prevu xen-3.3_3.3.0-1ubuntu7~hardy1.dsc
Build successful, attempt to install :-
root@boris-desktop:/var/cache/prevu/hardy-debs# ./install.sh

(Reading database … 101659 files and directories currently installed.)
Preparing to replace libxen3 3.2.0-0ubuntu10 (using libxen3_3.3.0-1ubuntu7~hardy1~8.04prevu1_amd64.deb) …
Unpacking replacement libxen3 …
Selecting previously deselected package libxen3-dev.
Unpacking libxen3-dev (from libxen3-dev_3.3.0-1ubuntu7~hardy1~8.04prevu1_amd64.deb) …
Selecting previously deselected package python-xen-3.3.
Unpacking python-xen-3.3 (from python-xen-3.3_3.3.0-1ubuntu7~hardy1~8.04prevu1_amd64.deb) …
Replacing files in old package python-xen-3.2 …
Selecting previously deselected package xen-docs-3.3.
Unpacking xen-docs-3.3 (from xen-docs-3.3_3.3.0-1ubuntu7~hardy1~8.04prevu1_amd64.deb) …
Selecting previously deselected package xen-hypervisor-3.3.
Unpacking xen-hypervisor-3.3 (from xen-hypervisor-3.3_3.3.0-1ubuntu7~hardy1~8.04prevu1_amd64.deb) …
Selecting previously deselected package xen-utils-3.3.
dpkg: regarding xen-utils-3.3_3.3.0-1ubuntu7~hardy1~8.04prevu1_amd64.deb containing xen-utils-3.3:
xen-utils-3.3 conflicts with xen-utils
xen-utils-3.2 provides xen-utils and is installed.
dpkg: error processing xen-utils-3.3_3.3.0-1ubuntu7~hardy1~8.04prevu1_amd64.deb (–install):
conflicting packages - not installing xen-utils-3.3
Setting up libxen3 (3.3.0-1ubuntu7~hardy1~8.04prevu1) …
Setting up libxen3-dev (3.3.0-1ubuntu7~hardy1~8.04prevu1) …
Setting up python-xen-3.3 (3.3.0-1ubuntu7~hardy1~8.04prevu1) …
Setting up xen-docs-3.3 (3.3.0-1ubuntu7~hardy1~8.04prevu1) …
Setting up xen-hypervisor-3.3 (3.3.0-1ubuntu7~hardy1~8.04prevu1) …
Searching for GRUB installation directory … found: /boot/grub
Searching for default file … found: /boot/grub/default
Testing for an existing GRUB menu.lst file … found: /boot/grub/menu.lst
Searching for splash image … none found, skipping …
Found Xen hypervisor 3.2, kernel: /boot/vmlinuz-2.6.24-21-xen
Found Xen hypervisor 3.3, kernel: /boot/vmlinuz-2.6.24-21-xen
Found kernel: /boot/vmlinuz-2.6.24-19-generic
Found kernel: /boot/memtest86+.bin
Replacing config file /var/run/grub/menu.lst with new version
Updating /boot/grub/menu.lst … done
Processing triggers for libc6 …
ldconfig deferred processing now taking place
Errors were encountered while processing:
xen-utils-3.3_3.3.0-1ubuntu7~hardy1~8.04prevu1_amd64.deb

I’ve tried to work with old package and force replacement as follows :-
root@boris-desktop:/var/cache/prevu/hardy-debs# dpkg -i –force-all xen-utils-3.3_3.3.0-1ubuntu7~hardy1~8.04prevu1_amd64.deb
dpkg: regarding xen-utils-3.3_3.3.0-1ubuntu7~hardy1~8.04prevu1_amd64.deb containing xen-utils-3.3:
xen-utils-3.3 conflicts with xen-utils
xen-utils-3.2 provides xen-u...

Read more...

Revision history for this message
Boris Derzhavets (bderzhavets) wrote :

To get Solaris 10/08 and Intrepid Server HVM able obtain IP address via bridge
i had to use vif = ['bridge=eth0'] in profiles like :-
root@boris-desktop:/etc/xen/vm# cat intrepid.hvm
kernel = “/usr/lib/xen/boot/hvmloader”
builder = ‘hvm’
memory = 1024
name = “IntrepidHVM”
vcpus = 1
vif = [ 'bridge=eth0' ]
disk = [ 'phy:/dev/sdb14,hda,w!','phy:/dev/loop0,hdc:cdrom,r' ]
device_model = ‘/usr/lib/xen/bin/qemu-dm’
vnc=1
boot=’c’
Turning virtual NIC into a paravirtualized mode instead of a fully virtualized.
When vif=['type=ioemu,bridge=eth0'] HVM fails to bring up virtual network interface.
Solaris 10/08 does have PV drivers,but Ubuntu Intrepid Server worked with
vif=['type=ioemu,bridge=eth0'] at Xen 3.3 CentOS 5.2 Dom0

Revision history for this message
Boris Derzhavets (bderzhavets) wrote :

I believe to realize what happened to Interpid Server HVM DomU.
Create Intrepid Server HVM DomU via :-
root@boris-desktop:/etc/xen/vm# cat intrepid.hvm
kernel = “/usr/lib/xen/boot/hvmloader”
builder = ‘hvm’
memory = 2048
name = “IntrepidHVM”
vcpus = 1
vif = [ 'bridge=eth0' ]
disk = [ 'phy:/dev/sdb14,hda,w!','phy:/dev/loop0,hdc:cdrom,r' ]
device_model = ‘/usr/lib/xen/bin/qemu-dm’
vnc=1
boot=’d’
The first time am image for PV DomU will be created, you won’t find any active Ethernet interface at HVM
DomU. However, install “Ubuntu Desktop” via tasksel at PV DomU will make it completely functional
to manage Intrepid Server HVM DomU. Seems like PV drivers for virtual NIC get installed on the
image device via tasksel’s procedure.

Revision history for this message
kantoka (kantoka) wrote :

How is the status on Xen 3.3 for Hardy?
What is the easiest way to upgrade 3.2 to 3.3 on a Hardy Xen?

Revision history for this message
Boris Derzhavets (bderzhavets) wrote :

>How is the status on Xen 3.3 for Hardy?
>What is the easiest way to upgrade 3.2 to 3.3 on a Hardy Xen?
View:-
http://lxer.com/module/newswire/view/112045/index.html

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.