FC4 on a FC5 Xen System
by Eredicator X
I am trying to install a FC4 domain on my Xen FC5 system that has several FC5 domains already running well.
I get through the install questions and then am told that my url is invalid. I thought it was my tree so I made another ... then tested that with a FC4 install on a separate box and it works fine. I don't see any hints in the logs and if I switch to my FC5 tree the install takes off with out a problem.
Can anyone point me to a tutorial or some reference for this.... I have googled around quite a bit and not found anything at this time......
Thanks all help is appreciated.
E./
17 years, 10 months
slow disk performance in Xen0 FC5
by Ashe Canvar
Hi all,
My dom0 and domU machines are showing terrible disk performance degradation.
For instance my avg data read rate ( tested using hdparm -t /dev/hda)
is 55MB/s using the regular smp kernel but it falls to 2.6MB/s when I
boot into dom0. No other domains are runnign at this point. I have
looked for incrementing interrupts in ide0 , there are none. hdparm
shows that dma mode is enabled. dmesg shows that the same driver is
being used for both smp and dom0 cases ( Uniform Multi-Platform E-IDE
driver Revision: 7.00alpha2 ).
I have total of 2Gig RAM in the box and dom0 is restricted to 512M.
Any help appreciated !
Thanks,
-ashe
[root@medusa1 ~]# rpm -qa | grep -i xen
kernel-xenU-2.6.16-1.2080_FC5
kernel-xen0-2.6.16-1.2080_FC5
xen-3.0.1-4
17 years, 11 months
Xen
by Manogna Ramakrishna Chebiyyam
hi everyone,
I work on fedora-core 5.I have been trying to install xen internally and i have been having problems.
I have successfully installed domain 0 but having problems with installing domain-U.
My hardware is SATA and this i have used LVM's.this is my partition
?????????????????????????????? Partitioning ??????????????????????????????
? ?
? Device Start End Size Type Mount Point ?
? VG VolGroup00 4960M VolGroup ? ?
? LV LogVol01 544M swap ? ?
? LV LogVol00 4416M ext3 / ? ?
? /dev/xvda ? ?
? xvda1 1 13 101M ext3 /boot ? ?
? xvda2 14 652 5012M physical v ? ?
? ? ?
? ? ?
? ? ?
? ? ?
and this is the error i get
Fedora Core
???????????????? Exception Occurred ????????????????
?????? ? ????
? ? Traceback (most recent call last): ? ? ?
? Na? File "/usr/bin/anaconda", line 1218, in ? ? ? ?
? Si? intf.run(id, dispatch) ? ? ?
? Su? File "/usr/lib/anaconda/text.py", line ? ? ?
? ? 535, in run ? ? ?
? ? dispatch.gotoNext() ? ? ?
? St? File "/usr/lib/anaconda/dispatch.py", line ? ? ?
? ? 146, in gotoNext ? ? ?
? ? self.moveStep() ? ? ?
? ? File "/usr/lib/anaconda/dispatch.py", line ? ? ?
? ? 217, in moveStep ? ? ?
? T? rc = apply(func, self.bindArgs(args)) ? ? ?
? C? ? ?
? R? ?????? ?????????? ????????? ? ?
? ? ? OK ? ? Remote ? ? Debug ? ? ?
? ? ?????? ?????????? ????????? ? ?
? ? ? ?
?????? ? ????
????????????????????????????????????????????????????
plzzz help me.Its an SOS call
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
17 years, 11 months
Re: [Fedora-xen] FC4 on a FC5 Xen System
by Eredicator X
----- Original Message -----
From: Ian Kent <ikent(a)redhat.com>
To: Eredicator X <eredicator(a)hugedesigns.net>
Cc: fedora-xen(a)redhat.com
Sent: Monday, June 5, 2006 5:29:32 PM GMT+0900
Subject: Re: [Fedora-xen] FC4 on a FC5 Xen System
On Mon, 2006-06-05 at 14:41 +0900, Eredicator X wrote:
> I am trying to install a FC4 domain on my Xen FC5 system that has several FC5 domains already running well.
>
> I get through the install questions and then am told that my url is invalid. I thought it was my tree so I made another ... then tested that with a FC4 install on a separate box and it works fine. I don't see any hints in the logs and if I switch to my FC5 tree the install takes off with out a problem.
>
> Can anyone point me to a tutorial or some reference for this.... I have googled around quite a bit and not found anything at this time......
I posted a similar question as well but with a slightly different view.
I bet you'll find that your build tree doesn't have an
images/xen/vmlinux or an images/xen/initrd.img (unless you've built
them). Then there's the problem that an FC4 tree doesn't (usually) have
a domU kernel either.
If they were there, such as with Rawhide, then it still fails to start
the install without any apparent clues in the log as far as I can see.
At least that's my experience.
Anyone willing to describe the process to build the boot kernel and init
ramdisk and a domU kernel for FC4?
Anyone know why the boot kernel and init ramdisk image in the Rawhide
tree doesn't seem to work from FC5?
Ian
Thanks Ian for making my request a little clearer.... I simply need to have a FC4 box so I can continue to use my current mail server and cut down on power consumption by combining boxes. This runs at my house and I pay the electric bill :(.
I have seen posts on the Xen users list where people are running multiple os's cent debian ect. on thier Xen servers, so it is possible, I just need the how.
Thanks again and any imput is appreciated.
E./
17 years, 11 months
fedora-xen-ia64 integration, step 1
by Aron Griffis
Hi Dave and Juan,
I'd like to get started on the path to integrating the fedora-xen-ia64
work into fedora. There are a number of pieces that I'll be trying to
pull together over the next few days. The biggest/hardest piece is
the kernel rpm.
I've split the changes into two parts:
1. generic fixes and enablement
2. ia64 xen integration
This mail contains the first part. For the second part, I'd like to
request that Juan updates his patch to the most recent xen-unstable
first. Then I'll work on making it build on ia64 and send back
whatever changes are necessary, including the ia64-xen[0U] configs.
Once the kernel rpm is working, it should be a relatively simple
matter to make the remainder of modifications to "turn on" xen-ia64.
Sound reasonable?
Regards,
Aron
--
This patch makes the following changes to the kernel specfile:
- abstract xenlinux build using xen_flags, xen_target and
xen_image instead of assuming x86 behavior
- add xen_* overrides to %ifarch ia64, won't be used until
buildxen is flipped on for ia64
- run the xen-mkbuildtree-pre hook following applying the xen
patch. This touches a couple files on ia64 but doesn't
interfere with any patching down the line. (I and others have
been submitting patches to xen-ia64-devel and xen-devel to
further reduce its function, but it should be harmless as-is.)
- update numerous hardcoded references to /boot to use
%{image_install_path} instead. But make an exception for the
xenU kernels which never need to be available for system
boot.
- build the hypervisor with %{?_smp_mflags} (it works fine)
Signed-off-by: Aron Griffis <aron(a)hp.com>
--- kernel-2.6.spec.orig 2006-06-01 19:12:59.000000000 -0400
+++ kernel-2.6.spec 2006-06-02 11:18:33.000000000 -0400
@@ -32,6 +32,9 @@
%define xen_version 20060524
%define make_target bzImage
%define kernel_image x86
+%define xen_flags verbose=y debug=y crash_debug=y
+%define xen_target vmlinuz
+%define xen_image vmlinuz
%define KVERREL %{PACKAGE_VERSION}-%{PACKAGE_RELEASE}
@@ -127,11 +130,15 @@
%endif
%ifarch ia64
-%define all_arch_configs $RPM_SOURCE_DIR/kernel-%{kversion}-ia64.config
+%define all_arch_configs $RPM_SOURCE_DIR/kernel-%{kversion}-ia64*.config
%define image_install_path boot/efi/EFI/redhat
%define signmodules 1
%define make_target compressed
%define kernel_image vmlinux.gz
+# ia64 doesn't building with debug=y at the moment
+%define xen_flags verbose=y crash_debug=y
+%define xen_target compressed
+%define xen_image vmlinux.gz
%endif
#
@@ -834,6 +841,15 @@
# Delete the rest of the backup files, they just confuse the build later
find -name "*.p.xen" | xargs rm -f
+# Run the xen-mkbuildtree-pre hook, if it exists for this architecture.
+# Hopefully this is kept clean (or non-existent) so that patches aren't confused
+# further down the line. Presently it's used only for ia64, and only for files
+# that we aren't interested in patching.
+if [[ -f "arch/%{_arch}/xen-mkbuildtree-pre" ]]; then
+ chmod +x arch/%{_arch}/xen-mkbuildtree-pre
+ arch/%{_arch}/xen-mkbuildtree-pre
+fi
+
#
# Xen includes a patch which moves the vsyscall fixmap into a user-space VA,
# freeing user-space from reliance on an absolute fixmap area and so allowing
@@ -1157,7 +1173,13 @@
mkdir -p $RPM_BUILD_ROOT/%{image_install_path}
install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer
install -m 644 System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer
- cp $KernelImage $RPM_BUILD_ROOT/%{image_install_path}/vmlinuz-$KernelVer
+ if [[ "$Flavour" == *xenU* ]]; then
+ # xenU kernels should always install to /boot
+ # because they're never needed for system boot
+ cp $KernelImage $RPM_BUILD_ROOT/boot/vmlinuz-$KernelVer
+ else
+ cp $KernelImage $RPM_BUILD_ROOT/%{image_install_path}/vmlinuz-$KernelVer
+ fi
if [ -f arch/$Arch/boot/zImage.stub ]; then
cp arch/$Arch/boot/zImage.stub $RPM_BUILD_ROOT/%{image_install_path}/zImage.stub-$KernelVer || :
fi
@@ -1293,15 +1315,15 @@
%if %{includexen}
%if %{buildxen}
cd xen
- mkdir -p $RPM_BUILD_ROOT/%{image_install_path}
+ mkdir -p $RPM_BUILD_ROOT/%{image_install_path} $RPM_BUILD_ROOT/boot
%if %{buildxenPAE}
- make debug=y verbose=y crash_debug=y pae=y
- install -m 644 xen.gz $RPM_BUILD_ROOT/boot/xen.gz-%{KVERREL}-PAE
+ make %{xen_flags} pae=y
+ install -m 644 xen.gz $RPM_BUILD_ROOT/%{image_install_path}/xen.gz-%{KVERREL}-PAE
install -m 755 xen-syms $RPM_BUILD_ROOT/boot/xen-syms-%{KVERREL}-PAE
make clean
%endif
- make debug=y verbose=y crash_debug=y
- install -m 644 xen.gz $RPM_BUILD_ROOT/boot/xen.gz-%{KVERREL}
+ make %{?_smp_mflags} %{xen_flags}
+ install -m 644 xen.gz $RPM_BUILD_ROOT/%{image_install_path}/xen.gz-%{KVERREL}
install -m 755 xen-syms $RPM_BUILD_ROOT/boot/xen-syms-%{KVERREL}
cd ..
%endif
@@ -1310,31 +1332,31 @@
cd linux-%{kversion}.%{_target_cpu}
%if %{buildup}
-BuildKernel %make_target %kernel_image
+BuildKernel %{make_target} %{kernel_image}
%endif
%if %{buildpae}
-BuildKernel %make_target %kernel_image PAE
+BuildKernel %{make_target} %{kernel_image} PAE
%endif
%if %{buildsmp}
-BuildKernel %make_target %kernel_image smp
+BuildKernel %{make_target} %{kernel_image} smp
%endif
%if %{includexen}
%if %{buildxenPAE}
-BuildKernel vmlinuz vmlinuz xen0-PAE
-BuildKernel vmlinuz vmlinuz xenU-PAE
+BuildKernel %{xen_target} %{xen_image} xen0-PAE
+BuildKernel %{xen_target} %{xen_image} xenU-PAE
%endif
%if %{buildxen}
-BuildKernel vmlinuz vmlinuz xen0
-BuildKernel vmlinuz vmlinuz xenU
+BuildKernel %{xen_target} %{xen_image} xen0
+BuildKernel %{xen_target} %{xen_image} xenU
%endif
%endif
%if %{buildkdump}
-BuildKernel %make_target %kernel_image kdump
+BuildKernel %{make_target} %{kernel_image} kdump
%endif
###
@@ -1443,7 +1465,7 @@
%post xen0
[ ! -x /usr/sbin/module_upgrade ] || /usr/sbin/module_upgrade %{rpmversion}-%{release}-xen0
-/sbin/new-kernel-pkg --package kernel-xen0 --mkinitrd --depmod --install --multiboot=/boot/xen.gz-%{KVERREL} %{KVERREL}xen0
+/sbin/new-kernel-pkg --package kernel-xen0 --mkinitrd --depmod --install --multiboot=/%{image_install_path}/xen.gz-%{KVERREL} %{KVERREL}xen0
[ ! -x /sbin/ldconfig ] || /sbin/ldconfig -X
%post xen0-devel
@@ -1469,7 +1491,7 @@
%post xen0-PAE
[ ! -x /usr/sbin/module_upgrade ] || /usr/sbin/module_upgrade %{rpmversion}-%{release}-xen0-PAE
-/sbin/new-kernel-pkg --package kernel-xen0-PAE --mkinitrd --depmod --install --multiboot=/boot/xen.gz-%{KVERREL}-PAE %{KVERREL}xen0-PAE
+/sbin/new-kernel-pkg --package kernel-xen0-PAE --mkinitrd --depmod --install --multiboot=/%{image_install_path}/xen.gz-%{KVERREL}-PAE %{KVERREL}xen0-PAE
[ ! -x /sbin/ldconfig ] || /sbin/ldconfig -X
%post xen0-PAE-devel
@@ -1611,7 +1633,7 @@
/%{image_install_path}/vmlinuz-%{KVERREL}xen0
/boot/System.map-%{KVERREL}xen0
/boot/config-%{KVERREL}xen0
-/boot/xen.gz-%{KVERREL}
+/%{image_install_path}/xen.gz-%{KVERREL}
/boot/xen-syms-%{KVERREL}
%dir /lib/modules/%{KVERREL}xen0
/lib/modules/%{KVERREL}xen0/kernel
@@ -1628,7 +1650,7 @@
%files xenU
%defattr(-,root,root)
-/%{image_install_path}/vmlinuz-%{KVERREL}xenU
+/boot/vmlinuz-%{KVERREL}xenU
/boot/System.map-%{KVERREL}xenU
/boot/config-%{KVERREL}xenU
%dir /lib/modules/%{KVERREL}xenU
@@ -1651,7 +1673,7 @@
/%{image_install_path}/vmlinuz-%{KVERREL}xen0-PAE
/boot/System.map-%{KVERREL}xen0-PAE
/boot/config-%{KVERREL}xen0-PAE
-/boot/xen.gz-%{KVERREL}-PAE
+/%{image_install_path}/xen.gz-%{KVERREL}-PAE
/boot/xen-syms-%{KVERREL}-PAE
%dir /lib/modules/%{KVERREL}xen0-PAE
/lib/modules/%{KVERREL}xen0-PAE/kernel
@@ -1668,7 +1690,7 @@
%files xenU-PAE
%defattr(-,root,root)
-/%{image_install_path}/vmlinuz-%{KVERREL}xenU-PAE
+/boot/vmlinuz-%{KVERREL}xenU-PAE
/boot/System.map-%{KVERREL}xenU-PAE
/boot/config-%{KVERREL}xenU-PAE
%dir /lib/modules/%{KVERREL}xenU-PAE
17 years, 11 months
xend hang on during startup on Bridge firewalling registered
by Christoph Ehret
Hi,
I just followed the instruction on
http://fedoraproject.org/wiki/FedoraXenQuickstartFC5 but when I boot on
the LinuxXen kernel, it hangs on
"Starting xend: Bridge firewalling registered"
and then I have seven or more lines of
vif0.0: received packet with own address as source address
Now, if I start in interactive mode and does not start xend during boot,
I can then log into the system and then start xend . Here I have again
these lines of vif0.0: received ... , but at least xend finishes the
start process.
What have I to do that I works without having to start in Interactive
mode and that the vif0.0: received... messages disappear ? Just to
mention that my laptop is not connected to the internet, but this should
not be the problem I think, isn't it ?
Thanks for your answers.
Seeu
Chris
17 years, 11 months
RE: [Fedora-xen] FW: [IA64]We have successfully booteddom0/domU/domVTI (xen/ia64) on FC5
by Zhang, Xiantao
>From the last mail:
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.
Thanks
-Xiantao
> -----Original Message-----
> From: Jeremy Katz [mailto:katzj@redhat.com]
> Sent: 2006年6月1日 4:52
> To: Aron Griffis
> Cc: Zhang, Xiantao; fedora-xen(a)redhat.com
> Subject: Re: [Fedora-xen] FW: [IA64]We have successfully
> booteddom0/domU/domVTI (xen/ia64) on FC5
>
> 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
17 years, 11 months
[RFC] cleanup warning (redefine MMIO_SIZE)
by Akio Takebe
Hi, all
This issue is only for fedora-xen-ia64.
fedora-xen-ia64 turn on CONFIG_FB_NEOMAGIC in .config.
(xen-ia64-unstable is default turn off it)
In the case of CONFIG_FB_NEOMAGIC=y, MMIO_SIZE is redefine.
I think MMIO_SIZE in arch-ia64.h is only used
in arch-ia64.h and xen/arch/ia64/vmx/vmx_init.c.
Am I right?
We should move some defines(e.g. MMIO_xxx) from public header
to not public header because they are used only
in vmx_init.c, shouldn't we?
fedora-xen-ia64's warning is:
In file included from drivers/video/neofb.c:85:
include/video/neomagic.h:136:1: warning: "MMIO_SIZE" redefined
In file included from include/xen/interface/xen.h:17,
from include/asm/hypervisor.h:41,
from include/asm/page.h:246,
from include/asm/ptrace.h:86,
from include/asm/processor.h:20,
from include/asm/thread_info.h:11,
from include/linux/thread_info.h:21,
from include/linux/preempt.h:10,
from include/linux/spinlock.h:50,
from include/linux/capability.h:45,
from include/linux/sched.h:7,
from include/linux/module.h:10,
from drivers/video/neofb.c:58:
include/xen/interface/arch-ia64.h:71:1: warning: this is the location of
the previous definition
Best Regards,
Akio Takebe
17 years, 11 months
HVM Loader Doesn't See the "vcpus" Parameter?
by Ahamed K, Rafiq (HP)
Every time "hvmloader" comes up to load a VM, it shows cpu=1 as
detected, no matter what number you give in .hvm configuration file. I
have vcpus=2 and cpus = "2-4" in my .hvm file!
Any idea why is this? Or Am I missing anything?
I am guessing due to this I am not able to run the un-modified
"Multiprocessor" Windows.
Any help would be appreciated.
Thanks R
These are the details of my configuration
I am having a server with 2 dual core XEON with VT-x enabled on it.
Linux linux 2.6.16.13-xen #2 SMP Wed May 24 10:41:28 MDT 2006 i686 i686
i386 GNU/Linux
linux:~ # xm info
host : linux
release : 2.6.16.13-xen
version : #2 SMP Wed May 24 10:41:28 MDT 2006
machine : i686
nr_cpus : 8
nr_nodes : 1
sockets_per_node : 2
cores_per_socket : 2
threads_per_core : 2
cpu_mhz : 2667
hw_caps :
bfebfbff:20100000:00000000:00000180:000064bd:00000000:00000001
total_memory : 3583
free_memory : 2522
xen_major : 3
xen_minor : 0
xen_extra : -unstable
xen_caps : xen-3.0-x86_32 hvm-3.0-x86_32
platform_params : virt_start=0xfc000000
xen_changeset : Sun May 21 20:15:58 2006 +0100
10058:14717dedba02
cc_compiler : gcc version 4.0.2 20050901 (prerelease) (SUSE
Linux)
cc_compile_by : root
cc_compile_domain : local
cc_compile_date : Wed May 24 10:31:04 MDT 2006
17 years, 11 months
NAT routing causes TCP checksum error
by Gary Shi
I've set up my a xen server as my LAN gateway, which has a DSL connection
and does NAT masquerade for the LAN, and I run several domU on the server
with routing network settings. All things work smoothly except the xenU
domains can't reach the internet with TCP: ping works fine, telnet can
establish connection and receive server packets, but real data packets sent
through ppp0 shows checksum error (tcpdump -vv shows cksum incorrect).
Then I found the problem on xensource community faq, and after I followed
his instruction to turned off the TX checksumming, my network works
properly.
http://wiki.xensource.com/xenwiki/XenFaq#head-4ce9767df34fe1c9cf4f85f7e07...
And here's a post describing some details, could you guys fix the problem in
xen0 kernel so we won't get stuck by this problem again?
http://lists.xensource.com/archives/html/xen-users/2006-04/msg00032.html
--
regards,
Gary Shi
17 years, 11 months
