Hello Centos,
I do not know if someone out there had/have this problems.
We have two HP-bl20p-G4 2xQuadCore Xeon E5320 Intel cpu's Blade. with following software on it
* centos 5.1 x86_64 * xen hypervisior 3.1 from centos distri.
And run on it following guests: 32bit centos4.6 domU's with xen_domU_kernel from update repo.
Some of this machines are running fine and some of this are dying sometimes under load or no load. It look's for me strange.
So my question is there a basic problem to run domU32 bit systems on a 64bit hardware ? If i read the newest messages on xen this is now a big goal for xen 3.1 but i know it can be a bug or a misunderstood config on my side.
Hopefully someone out there can help me with this problem.
I attached some error outputs. If you need some more information's please let me know.
greets Michael
Here are some domU error's and core dumps: ---
one of the error with an older xen domU kernel: ----------------------------------------------- kernel BUG at arch/i386/mm/hypervisor.c:195! invalid operand: 0000 [#1] SMP Modules linked in: md5(U) ipv6(U) sunrpc(U) dm_mirror(U) dm_mod(U) ext3(U) jbd(U) CPU: 0 EIP: 0061:[<c0115709>] Not tainted VLI EFLAGS: 00010282 (2.6.9-42.0.3.EL.xs0.4.0.263xenU) EIP is at xen_pgd_pin+0x44/0x52 eax: ffffffea ebx: eb500e4c ecx: 00000001 edx: 00000000 esi: 00007ff0 edi: ebb7b840 ebp: ebb7b0c0 esp: eb500e4c ds: 007b es: 007b ss: 0068 Process sh (pid: 2872, threadinfo=eb500000 task=eb712d10) Stack: 00000002 00225f7b 2b70c000 ebb7b0c0 0056e180 ebb7b0c0 c011222f ebb7b104 c01122bb ebb7b870 eb500000 c0160cf0 ebb7b840 eb712d10 c013ae9c 00000080 c016fcd9 00000080 ebb07580 00000080 ebc90840 c0157cd9 00000000 eb500000 ebbaa740 c2338c00 c0160ed9 c0160c05 eb500ec0 00000080 eb87d4c0 00400000 Call Trace: [<c011222f>] __pgd_pin+0x2a/0x3b [<c01122bb>] mm_pin+0x1f/0x2b [<c0160cf0>] exec_mmap+0xe1/0x223 [<c013ae9c>] generic_file_aio_read+0x40/0x47 [<c016fcd9>] dnotify_parent+0x1b/0x6e [<c0157cd9>] vfs_read+0xda/0xe2 [<c0160ed9>] flush_old_exec+0x43/0x21e [<c0160c05>] kernel_read+0x31/0x3b [<c017c497>] load_elf_binary+0x520/0xc83 [<c0145d99>] kmap_high +0x1e9/0x1f3 [<c0145e1b>] kunmap_high+0x78/0x95 [<c0160755>] copy_strings+0x22b/0x235 [<c017bf77>] load_elf_binary+0x0/0xc83 [<c016191c>] search_binary_handler+0xb7/0x22a [<c0161bfc>] do_execve +0x16d/0x1fd [<c0105d82>] sys_execve+0x2b/0x8a [<c02564f7>] syscall_call+0x7/0xb [<c025007b>] unix_stream_sendmsg+0x147/0x33a Code: 00 75 0d a1 a4 40 33 c0 8b 04 90 25 ff ff ff 7f 89 44 24 04 89 e3 b9 01 00 00 00 31 d2 be f0 7f 00 00 e8 3b bc fe ff 85 c0 79 08 <0f> 0b c3 00 a4 c4 26 c0 83 c4 10 5b 5e c3 56 89 c2 c1 ea 0c 53 <0>Fatal exception: panic in 5 seconds
And one of the new one: ----------------------- Jan 17 13:15:22 PHOEBE kernel: ------------[ cut here ]------------ Jan 17 13:15:22 PHOEBE kernel: kernel BUG at mm/swap.c:324! Jan 17 13:15:22 PHOEBE kernel: invalid operand: 0000 [#1] Jan 17 13:15:22 PHOEBE kernel: SMP Jan 17 13:15:22 PHOEBE kernel: Modules linked in: md5 ipv6 nfs lockd nfs_acl sunrpc iptable_filter ip_tables dm_mirror dm_mod xennet ext3 jbd xenblk
On Jan 17, 2008 3:29 PM, Theurl Michael michael.theurl@smog.at wrote:
I do not know if someone out there had/have this problems.
We have two HP-bl20p-G4 2xQuadCore Xeon E5320 Intel cpu's Blade. with following software on it
- centos 5.1 x86_64
- xen hypervisior 3.1 from centos distri.
And run on it following guests: 32bit centos4.6 domU's with xen_domU_kernel from update repo.
Some of this machines are running fine and some of this are dying sometimes under load or no load. It look's for me strange.
So my question is there a basic problem to run domU32 bit systems on a 64bit hardware ? If i read the newest messages on xen this is now a big goal for xen 3.1 but i know it can be a bug or a misunderstood config on my side.
Hopefully someone out there can help me with this problem.
...snip...
Hi Michael,
Support for running 32 bit Paravirt Xen VM's on a 64bit host was added to 5.1 as a technology preview by the upstream provider. This means that this has not been fully tested and is not supported.
I've also have been testing this and I had the same issues. Most of the times I could not even get a install to finish.
So I guess the best thing to do is to create tickets for this in the upstreams bugzilla and hope they have fixed the issues for 5.2
Regards, Tim
Hello Tim,
this information is pure gold for me :) thanxs a lot.
greets
Michael
On Thu, 2008-01-17 at 15:35 +0100, Tim Verhoeven wrote:
On Jan 17, 2008 3:29 PM, Theurl Michael michael.theurl@smog.at wrote:
I do not know if someone out there had/have this problems.
We have two HP-bl20p-G4 2xQuadCore Xeon E5320 Intel cpu's Blade. with following software on it
- centos 5.1 x86_64
- xen hypervisior 3.1 from centos distri.
And run on it following guests: 32bit centos4.6 domU's with xen_domU_kernel from update repo.
Some of this machines are running fine and some of this are dying sometimes under load or no load. It look's for me strange.
So my question is there a basic problem to run domU32 bit systems on a 64bit hardware ? If i read the newest messages on xen this is now a big goal for xen 3.1 but i know it can be a bug or a misunderstood config on my side.
Hopefully someone out there can help me with this problem.
...snip...
Hi Michael,
Support for running 32 bit Paravirt Xen VM's on a 64bit host was added to 5.1 as a technology preview by the upstream provider. This means that this has not been fully tested and is not supported.
I've also have been testing this and I had the same issues. Most of the times I could not even get a install to finish.
So I guess the best thing to do is to create tickets for this in the upstreams bugzilla and hope they have fixed the issues for 5.2
Regards, Tim
Tim Verhoeven wrote:
On Jan 17, 2008 3:29 PM, Theurl Michael michael.theurl@smog.at wrote:
Support for running 32 bit Paravirt Xen VM's on a 64bit host was added
Where did the OP say paravirt? I would expect any quad-code Intel CPUs to provide hardware virtualisation.
John,
John Summerfield wrote:
Tim Verhoeven wrote:
On Jan 17, 2008 3:29 PM, Theurl Michael michael.theurl@smog.at wrote:
Support for running 32 bit Paravirt Xen VM's on a 64bit host was added
Where did the OP say paravirt? I would expect any quad-code Intel CPUs to provide hardware virtualisation.
Go read the docs.
Also you seem confused between the idea of paravirt and fullvirt. They are not the same thing and not inter-reverseable.
Karanbir Singh wrote:
John,
John Summerfield wrote:
Tim Verhoeven wrote:
On Jan 17, 2008 3:29 PM, Theurl Michael michael.theurl@smog.at wrote:
Support for running 32 bit Paravirt Xen VM's on a 64bit host was added
Where did the OP say paravirt? I would expect any quad-code Intel CPUs to provide hardware virtualisation.
Go read the docs.
What docs?
Also you seem confused between the idea of paravirt and fullvirt. They are not the same thing and not inter-reverseable.
I know that, I have bought a dual-core Intellish box for that reason.
On Jan 18, 2008 2:25 AM, John Summerfield debian@herakles.homelinux.org wrote:
Tim Verhoeven wrote:
On Jan 17, 2008 3:29 PM, Theurl Michael michael.theurl@smog.at wrote:
Support for running 32 bit Paravirt Xen VM's on a 64bit host was added
Where did the OP say paravirt? I would expect any quad-code Intel CPUs to provide hardware virtualisation.
Those CPU's most likely support HVM. But running a 32bit domU using HVM on a 64bit host has always worked for me (even since 5.0). And since the error the OP reported was the same as I had with my attemps using PVM it seemed reasonable to assume the OP was using PVM.
Regards, Tim
Tim Verhoeven wrote:
On Jan 18, 2008 2:25 AM, John Summerfield debian@herakles.homelinux.org wrote:
Tim Verhoeven wrote:
On Jan 17, 2008 3:29 PM, Theurl Michael michael.theurl@smog.at wrote: Support for running 32 bit Paravirt Xen VM's on a 64bit host was added
Where did the OP say paravirt? I would expect any quad-code Intel CPUs to provide hardware virtualisation.
Those CPU's most likely support HVM. But running a 32bit domU using
They do: http://processorfinder.intel.com/Details.aspx?sSpec=SL9MV
HVM on a 64bit host has always worked for me (even since 5.0). And since the error the OP reported was the same as I had with my attemps using PVM it seemed reasonable to assume the OP was using PVM.
You might be right, but Prudence says that as the OP as a choice, one should check.
Since the OP has the choice, trying the other might work better.
Tim Verhoeven wrote:
Those CPU's most likely support HVM.
that still does not guarantee that HVM will work, plenty of machines floating around with HVM disabled at various levels.
-
John Summerfield -
Karanbir Singh -
Theurl Michael -
Tim Verhoeven