After some hard debug and work around, now we've got xen/ia64
dom0/domU/domVTI both up on FC5-IA64. Attached is the snapshot. Woohoo! :-)
We still use python2.4.2 contained in FC5 for test. We need following changes to make things happen:
- xen-tools is not built and integrated into the RPM package.
Typically we know there're 3 major directories on xen-ia64-unstable.hg: xen,linux-sparse and tools. All three need to be kept consistence with each other. However current fedora-kernel-ia64 only incorporates former two and tools is totally missed. We tried to build the tools individually from xen-ia64-unstable under same Rev (10150), and then install to target box manually.
You need to install the xen rpm which is available from my yum repository. See here for instructions: https://www.redhat.com/archives/fedora-xen/2006-May/msg00140.html
OK, we will do a try.
- The configuration files for dom0/domU seems a big difference
compared to xen-ia64-unstable.hg. (Why?) Currently the ext3 is compiled as module, however initrd doesn't work for domU even when we add "ramdisk=" in config file. So we change ext3 to be kernel built-in, and then domU can boot up immediately.
Ok, I'll fix that in the rpm.
OK.
- Xen-ia64-unstable.hg doesn't have IDE devices configured for
domU, however fedora-kernel-ia64 does, which wastes much time for probe. If the configuration file can be kept consistence with xen-ia64-unstable.hg, above issues are gone.
That's my mistake too. I'll fix it.
OK too:)
After above 2 changes, both domU and domVTI can be boot
successfully.
Following are other tricky issues we've observed:
- brctl package is not integrated into FC5 and so vnif is not
available now. People need to install brctl manually and we'll try network later. Is it possible to add dependency check upon brctl in spec file?
The dependency is in the xen rpm...
Clear now.
- When installing xen0 rpm package, it depends on xen rpm
package. However we didn't find the xen rpm package, and had to install with "nodeps". Actually xen image has been included in xen0 rpm package.
This is a confusing misnomer in Fedora. The xen rpm contains the xen tools, not the xen hypervisor. Does this make things clearer?
See now. Different viewpoint to it:)
- Is it possible to use same configuration file for xen0/xenU
just like current xen-ia64-unstable.hg? Or at least give a configuration option to user in spec.
Right now the build follows the pattern of the other architectures in the spec file. If Juan is interested in pursuing a -xen kernel instead of -xen0/-xenU, I'd be happy to go that route.
Good news! If done, it will largely save build time.
Thanks Xiantao
Zhang, Xiantao wrote: [Fri May 26 2006, 09:38:51AM EDT]
- The configuration files for dom0/domU seems a big difference
compared to xen-ia64-unstable.hg. (Why?) Currently the ext3 is compiled as module, however initrd doesn't work for domU even when we add "ramdisk=" in config file. So we change ext3 to be kernel built-in, and then domU can boot up immediately.
Ok, I'll fix that in the rpm.
OK.
I added ext3 as 'y' instead of module, this is now in the fedora-kernel-ia64 repo.
- Xen-ia64-unstable.hg doesn't have IDE devices configured for
domU, however fedora-kernel-ia64 does, which wastes much time for probe. If the configuration file can be kept consistence with xen-ia64-unstable.hg, above issues are gone.
That's my mistake too. I'll fix it.
OK too:)
On investigation, I don't see IDE configured for the xenU kernel. Could you point out the specific problem, or send a patch to the config?
Thanks, Aron
On Wed, 2006-05-31 at 15:13 -0400, Aron Griffis wrote:
Zhang, Xiantao wrote: [Fri May 26 2006, 09:38:51AM EDT]
- The configuration files for dom0/domU seems a big difference
compared to xen-ia64-unstable.hg. (Why?) Currently the ext3 is compiled as module, however initrd doesn't work for domU even when we add "ramdisk=" in config file. So we change ext3 to be kernel built-in, and then domU can boot up immediately.
Ok, I'll fix that in the rpm.
OK.
I added ext3 as 'y' instead of module, this is now in the fedora-kernel-ia64 repo.
Things are configured as they are so that we don't have configuration skew between Xen and non-Xen kernels as that just leads to confusion and tool problems down the road. What's the problem with initrds and ia64 xen?
Jeremy