Hi We would like to buy a new server-hardware for a xen-server. We are going to run linux as dom0 and domU. The whole server will have 4 GB of main memory. Do you got any suggestions if it is better to buy an opteron (amd64) cpu, or an intel (ia32) cpu? A opteron is much better, if you need more than 2 gb in the userspace, but intel has virtualization build into hardware. We currently tend to buy and amd64, has somebody an amd64 system running, with i386 and amd64 domU systems mixed, or does know if it is possible and/or stable? Is an intel cpu much faster when using vanderpool, then an amd64 running in 32 bit mode without any special hardware support? -- Warning: Dates in Calendar are closer than they appear! _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
hello, amd announced their "vanderpool" like technology called "pacifica" or "iommu" to be available in all their newly released processors from this month on (see amd press releases). amd''s tech has some potential advantages right now because the mmu is located within the cpu and so supports some advanced tricks very handy for vitualization(nested page tables etc.). on the other hand some reports say if you want to have more virtual machines than actual processor cores intel''s hyperthreading is the way to go. intel also wants to release virtualization optimized chipsets (i.e. northbridges that do the same tricks as amd''s mmu). On Thu, 09 Mar 2006 21:02:41 +0100, Erik Tews <erik@debian.franken.de> wrote:> Hi > > We would like to buy a new server-hardware for a xen-server. We are > going to run linux as dom0 and domU. The whole server will have 4 GB of > main memory. Do you got any suggestions if it is better to buy an > opteron (amd64) cpu, or an intel (ia32) cpu? A opteron is much better, > if you need more than 2 gb in the userspace, but intel has > virtualization build into hardware. > > We currently tend to buy and amd64, has somebody an amd64 system > running, with i386 and amd64 domU systems mixed, or does know if it is > possible and/or stable? Is an intel cpu much faster when using > vanderpool, then an amd64 running in 32 bit mode without any special > hardware support?-- Using Opera''s revolutionary e-mail client: http://www.opera.com/mail/ _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Am Donnerstag, den 09.03.2006, 21:44 +0100 schrieb aschiefer@vub.de:> hello, > > amd announced their "vanderpool" like technology called "pacifica" or > "iommu" to be available in all their newly released processors from this > month on (see amd press releases). amd''s tech has some potential > advantages right now because the mmu is located within the cpu and so > supports some advanced tricks very handy for vitualization(nested page > tables etc.). on the other hand some reports say if you want to have more > virtual machines than actual processor cores intel''s hyperthreading is the > way to go. intel also wants to release virtualization optimized chipsets > (i.e. northbridges that do the same tricks as amd''s mmu).Thats cool. How can I find out if a cpu from amd supports pacifica? I thought it would take much longer for them to bring these cpus to the market. Do you got an url from this press announcement? Does xen 3.0 support pacifica at the moment, and does it run stable? _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
hello, maybe i was writing a bit to amd marketing like, excuse me for that. they want to integrate pacifica into all their "newly released" processor, which means the processors are not yet available. the link is http://www.amd.com/us-en/Corporate/VirtualPressRoom/0,,51_104_543~104860,00.html, but the thing you are probably most interested in is(quote): AMD?s I/O virtualization technology is expected to be supported by all AMD processors in mid-2006, and is also anticipated to be implemented in chipsets and core logic designed for AMD64-based platforms in 2006. The AMD I/O virtualization technology specification download, together with technology overviews and guidance to software developers who are designing virtualization solutions for 64-bit technology, can be found at http://developer.amd.com.> On Thu, 09 Mar 2006 21:53:07 +0100, Erik Tews <erik@debian.franken.de> > wrote: > >> Am Donnerstag, den 09.03.2006, 21:44 +0100 schrieb aschiefer@vub.de: >>> hello, >>> >>> amd announced their "vanderpool" like technology called "pacifica" or >>> "iommu" to be available in all their newly released processors from >>> this >>> month on (see amd press releases). amd''s tech has some potential >>> advantages right now because the mmu is located within the cpu and so >>> supports some advanced tricks very handy for vitualization(nested page >>> tables etc.). on the other hand some reports say if you want to have >>> more >>> virtual machines than actual processor cores intel''s hyperthreading is >>> the >>> way to go. intel also wants to release virtualization optimized >>> chipsets >>> (i.e. northbridges that do the same tricks as amd''s mmu). >> >> Thats cool. How can I find out if a cpu from amd supports pacifica? I >> thought it would take much longer for them to bring these cpus to the >> market. Do you got an url from this press announcement? >> >> Does xen 3.0 support pacifica at the moment, and does it run stable? >> >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xensource.com >> http://lists.xensource.com/xen-users > > >-- Using Opera''s revolutionary e-mail client: http://www.opera.com/mail/ _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Am Donnerstag, den 09.03.2006, 22:50 +0100 schrieb aschiefer@vub.de:> hello, > maybe i was writing a bit to amd marketing like, excuse me for that. they > want to integrate pacifica into all their "newly released" processor, > which means the processors are not yet available. the link is > http://www.amd.com/us-en/Corporate/VirtualPressRoom/0,,51_104_543~104860,00.html, > but the thing you are probably most interested in is(quote): > AMD?s I/O virtualization technology is expected to be supported by all > AMD processors in mid-2006, and is also anticipated to be implemented in > chipsets and core logic designed for AMD64-based platforms in 2006. The > AMD I/O virtualization technology specification download, together with > technology overviews and guidance to software developers who are > designing virtualization solutions for 64-bit technology, can be found > at http://developer.amd.com.Thanks again. But I think there are currently no real devices available you can buy with pacifica-support. So I think I will have to compare opterons without pacifica support to intel cpus with vanderpool-support, because I can currently buy such cpus. So how can those cpus be compared, if I need a system with 4 gb of ram? Giving more than 2 GB to a single userspace process on an 32 bit system can be quite difficult. Does an opteron cpu run fine with xen 3.0 in 64 bit mode, with some 32 bit guests, without any hardware accelleration? _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
hello, as i mentioned earlier (sorry i don''t remember the source anymore), i read a test which said as long as you have only as many vm''s as actual processor cores the opteron is better, otherwise intel was better due to its hyperthreading. the performance loss is already low now for both plattforms (we measured less than ca. 5%), i only experience signifcant performance problems with the gbit network of the domUs. ciao, artur Am Freitag, den 10.03.2006, 02:22 +0100 schrieb Erik Tews:> Am Donnerstag, den 09.03.2006, 22:50 +0100 schrieb aschiefer@vub.de: > > hello, > > maybe i was writing a bit to amd marketing like, excuse me for that. they > > want to integrate pacifica into all their "newly released" processor, > > which means the processors are not yet available. the link is > > http://www.amd.com/us-en/Corporate/VirtualPressRoom/0,,51_104_543~104860,00.html, > > but the thing you are probably most interested in is(quote): > > AMD?s I/O virtualization technology is expected to be supported by all > > AMD processors in mid-2006, and is also anticipated to be implemented in > > chipsets and core logic designed for AMD64-based platforms in 2006. The > > AMD I/O virtualization technology specification download, together with > > technology overviews and guidance to software developers who are > > designing virtualization solutions for 64-bit technology, can be found > > at http://developer.amd.com. > > Thanks again. > > But I think there are currently no real devices available you can buy > with pacifica-support. > > So I think I will have to compare opterons without pacifica support to > intel cpus with vanderpool-support, because I can currently buy such > cpus. > > So how can those cpus be compared, if I need a system with 4 gb of ram? > Giving more than 2 GB to a single userspace process on an 32 bit system > can be quite difficult. Does an opteron cpu run fine with xen 3.0 in 64 > bit mode, with some 32 bit guests, without any hardware accelleration? >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Friday 10 March 2006 11:15, Artur Schiefer wrote:> hello, > > as i mentioned earlier (sorry i don''t remember the source anymore), i > read a test which said as long as you have only as many vm''s as actual > processor cores the opteron is better, otherwise intel was better due to > its hyperthreading. the performance loss is already low now for both > plattforms (we measured less than ca. 5%), i only experience signifcant > performance problems with the gbit network of the domUs. >I remember reading a mail here saying you''re better off disabling HT on Intel when running Xen, as it causes a major slowdown if the two threads are assigned to different domUs. There was no explanation given, so I''m not sure if thats true. (Maybe problems with pagetable cache?) /Ernst _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
The virtualization hardware only helps you when you have OSes that are not Xen aware. Since you say you just want to run linux, the vanderpool and pacifica extensions will do nothing for you. Also (someone correct me if I''m wrong), Xen aware linux is faster than fully virtualized linux. As for 32 bit vs 64 bit kernels, you generally cannot mix both on the same physical hardware. Vanderpool/Pacifica allows you to break this. Cheers, Dan. (This email brought to you by a domU mailserver passing through a domU firewall) Erik Tews wrote:>Hi > >We would like to buy a new server-hardware for a xen-server. We are >going to run linux as dom0 and domU. The whole server will have 4 GB of >main memory. Do you got any suggestions if it is better to buy an >opteron (amd64) cpu, or an intel (ia32) cpu? A opteron is much better, >if you need more than 2 gb in the userspace, but intel has >virtualization build into hardware. > >We currently tend to buy and amd64, has somebody an amd64 system >running, with i386 and amd64 domU systems mixed, or does know if it is >possible and/or stable? Is an intel cpu much faster when using >vanderpool, then an amd64 running in 32 bit mode without any special >hardware support? > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Daniel Goertzen <goertzen@ertw.com> writes:> The virtualization hardware only helps you when you have OSes that are > not Xen aware. Since you say you just want to run linux, the > vanderpool and pacifica extensions will do nothing for you. Also > (someone correct me if I''m wrong), Xen aware linux is faster than > fully virtualized linux.It depends. In theory SVM(=Pacifica)/VMX can do some things like system calls more efficiently. For other things Xen aware is better. But overall the jury is still out because the implementations of VMX/SVM are not particularly optimized yet. Especially the Xen aware drivers are much better than the emulated device model in the native guests, but there is no reason you couldn''t later use Xen aware driver with an otherwise non Xen aware OS (but I don''t think that works right now) So right now Xen aware Linux should be faster in most cases, but longer term fully virtualized might catch up and be better for some cses.> As for 32 bit vs 64 bit kernels, you generally cannot mix both on the > same physical hardware. Vanderpool/Pacifica allows you to break this.I don''t think that''s fully true for domUs, although you cannot mix non PAE and PAE kernels (and 64bit hypervisor implies PAE). But I would expect this limitation to fall at some point too so that you could possibly run non PAE Xen aware kernels on PAE or 64bit Hypervisors. For dom0s the domain has to match the hypervisor, same for the the admin tools. -Andi _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
>> as i mentioned earlier (sorry i don''t remember the source anymore), i >> read a test which said as long as you have only as many vm''s as actual >> processor cores the opteron is better, otherwise intel was better due to >> its hyperthreading. the performance loss is already low now for both >> plattforms (we measured less than ca. 5%), i only experience signifcant >> performance problems with the gbit network of the domUs. >> > I remember reading a mail here saying you''re better off disabling HT on > Intel when running Xen, as it causes a major slowdown if the two threads > are assigned to different domUs. > > There was no explanation given, so I''m not sure if thats true. (Maybe > problems with pagetable cache?)Depends what you''re doing with the hyperthreads... HT is happiest when the activities of the two threads are using the same working set in the cache, so they don''t fight over cache space. If they''re actually two different virtual machines then they''re definitely not using the same working set (as things stand today, since there is no large scale data sharing), so the cache behaviour cannot be expected to be helpful and may be harmful to performance. HOWEVER Dedicating a hyperthread to dom0 may benefit performance. Particularly in the case where it''s impossible to dedicate an entire core to dom0 (e.g. you only have a uniprocessor). Since IO has to happen through dom0, it''s beneficial for it to have a logical CPU to itself to run on all the time, so that a context switch isn''t necessary for IO to be performed. This effect is most noticeable when running under heavy network loads and had a fairly large benefit in our benchmarks vs the non-HT uniprocessor case. Cheers, Mark _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Friday 10 March 2006 9:23 am, Daniel Goertzen wrote:> and pacifica extensions will do nothing for you. Also (someone correct > me if I''m wrong), Xen aware linux is faster than fully virtualized linux.i guess you''re right on this, and also there are some limitations on the qemu emulation of hard drive controllers. i''m not sure if it''s the same on Xen, but at least qemu 0.8 doesn''t do LBA48, therefore the virtual drives are limited to 137GB (or 128GiB) -- Javier _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
as far as i understand (i may be wrong here too) vt and pacifca support some operations in hardware (or plan to do so in matching chipsets), which earlier had to done in software (e.g. device i/o virtualization, mmu virtualization), from which one could expect at least some perfomance gain. but since the overall xen peformance is already close to non virtualized hardware, maybe it''s not really worth waiting for (in case of linux). On Fri, 10 Mar 2006 23:49:54 +0100, Javier Guerra <javier@guerrag.com> wrote:> On Friday 10 March 2006 9:23 am, Daniel Goertzen wrote: >> and pacifica extensions will do nothing for you. Also (someone correct >> me if I''m wrong), Xen aware linux is faster than fully virtualized >> linux. > > i guess you''re right on this, and also there are some limitations on the > qemu > emulation of hard drive controllers. i''m not sure if it''s the same on > Xen, > but at least qemu 0.8 doesn''t do LBA48, therefore the virtual drives are > limited to 137GB (or 128GiB) > >-- Using Opera''s revolutionary e-mail client: http://www.opera.com/mail/ _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
We have a quad core opteron system with 8GB of RAM, running Gentoo (compiled for 64 bit kernel and userspace) and we run a mix of 32 bit and 64 bit dom-U''s. On Thursday 09 March 2006 14:02, Erik Tews wrote:> Hi > > We would like to buy a new server-hardware for a xen-server. We are > going to run linux as dom0 and domU. The whole server will have 4 GB of > main memory. Do you got any suggestions if it is better to buy an > opteron (amd64) cpu, or an intel (ia32) cpu? A opteron is much better, > if you need more than 2 gb in the userspace, but intel has > virtualization build into hardware. > > We currently tend to buy and amd64, has somebody an amd64 system > running, with i386 and amd64 domU systems mixed, or does know if it is > possible and/or stable? Is an intel cpu much faster when using > vanderpool, then an amd64 running in 32 bit mode without any special > hardware support?-- Edward Muller Interlix, LLC _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Am Mittwoch 12 April 2006 03:26 schrieb Edward Muller:> We have a quad core opteron system with 8GB of RAM, running Gentoo > (compiled for 64 bit kernel and userspace) and we run a mix of 32 bit and > 64 bit dom-U''s.Something similar here: AMD64 with 4GB RAM running a 64-bit Gentoo Dom0, running 30 DomUs, which are mixed 32-bit Debian/SuSE/FC4/CentOS and 64-bit Gentoo, but all with a 64-bit kernel for the DomU. If you don''t choose stupid compiler-settings (beware of -Os, it creates broken code), it''s running very, very smoothly. --- Heiko. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Heiko, On 4/12/06, Heiko Wundram <me+xen-users@modelnine.org> wrote:> Am Mittwoch 12 April 2006 03:26 schrieb Edward Muller: > > We have a quad core opteron system with 8GB of RAM, running Gentoo > > (compiled for 64 bit kernel and userspace) and we run a mix of 32 bit and > > 64 bit dom-U''s. > > Something similar here: AMD64 with 4GB RAM running a 64-bit Gentoo Dom0, > running 30 DomUs, which are mixed 32-bit Debian/SuSE/FC4/CentOS and 64-bit > Gentoo, but all with a 64-bit kernel for the DomU. If you don''t choose stupid > compiler-settings (beware of -Os, it creates broken code), it''s running very, > very smoothly.Can i ask what kind of thing these servers are doing? And also how many processors your server has? _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Am Mittwoch 12 April 2006 07:25 schrieb Simon:> Can i ask what kind of thing these servers are doing? And also how > many processors your server has?Virtual dedicated server hosting (with between 48 MB and 192 MB RAM per DomU, and the storage running on a Hardware SATA RAID-1, with EVMS as the kernel storage layer). And each server has two CPUs. --- Heiko. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
I first had also a mixed 64/32 bit setup with Xen 3.0.1: AMD64, 4GB RAM, 2x250GB SATA Drives with a mix of software raid 1 and raid 0 (for tmp and swap). The domU partitions were on LVM''s, OS was debian sarge amd64 + i386. Most 32 and 64 bit domU''s were working fine, but there was one problem I could not get fixed (and why I finally changed everything to plain 32 bit using Xen 3.0.2 and debian etch-b2): I could never connect to a DB2 instance running in a 32 bit domU because it complained about not enough shared memory. I tried every suggestion I could find, but finally found that the output if "ipcs -l" did lack shared memory completely in 32 bit domU''s whatever shared memory setting I tried. So when the output is normally something as: ------ Shared Memory Limits -------- max number of segments = 4096 max seg size (kbytes) = 32768 max total shared memory (pages) = 2097152 min seg size (bytes) = 1 ------ Semaphore Limits -------- max number of arrays = 128 max semaphores per array = 250 max semaphores system wide = 32000 max ops per semop call = 32 semaphore max value = 32767 ------ Messages: Limits -------- max queues system wide = 16 max size of message (bytes) = 8192 default max size of queue (bytes) = 16384 In a 32 bit domU under 64 bit xen/dom0 it showed up as: ------ Shared Memory Limits -------- ------ Semaphore Limits -------- max number of arrays = 128 max semaphores per array = 250 max semaphores system wide = 32000 max ops per semop call = 32 semaphore max value = 32767 ------ Messages: Limits -------- max queues system wide = 16 max size of message (bytes) = 8192 default max size of queue (bytes) = 16384 Interestingly Oracle which also run in a 32 bit domU was not affected. What does ipcs -l show in your 32 bit domU''s? Seneca You wrote at Mittwoch, 12. April 2006 07:02: HW> Am Mittwoch 12 April 2006 03:26 schrieb Edward Muller:>> We have a quad core opteron system with 8GB of RAM, running Gentoo >> (compiled for 64 bit kernel and userspace) and we run a mix of 32 bit and >> 64 bit dom-U''s.HW> Something similar here: AMD64 with 4GB RAM running a 64-bit Gentoo Dom0, HW> running 30 DomUs, which are mixed 32-bit Debian/SuSE/FC4/CentOS and 64-bit HW> Gentoo, but all with a 64-bit kernel for the DomU. If you don''t choose stupid HW> compiler-settings (beware of -Os, it creates broken code), it''s running very, HW> very smoothly. HW> --- Heiko. HW> _______________________________________________ HW> Xen-users mailing list HW> Xen-users@lists.xensource.com HW> http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Wednesday 12 April 2006 1:19 am, Heiko Wundram wrote:> Virtual dedicated server hosting (with between 48 MB and 192 MB RAM per > DomU, and the storage running on a Hardware SATA RAID-1, with EVMS as the > kernel storage layer). And each server has two CPUs.it''s a bit OT, but... how do you find managing Gentoo for server? i''ve tried it a couple of times, and couldn''t find a midpoint between updating too often (often breaking config files) and the needed stability for a server. also, i couldn''t find any cluster-aware tools for EVMS (like clvm for LVM2), is there anything like that? -- Javier _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 4/12/06, Heiko Wundram <me+xen-users@modelnine.org> wrote:> > Something similar here: AMD64 with 4GB RAM running a 64-bit Gentoo Dom0, > running 30 DomUs, which are mixed 32-bit Debian/SuSE/FC4/CentOS and 64-bit > Gentoo, but all with a 64-bit kernel for the DomU. If you don''t choose > stupid > compiler-settings (beware of -Os, it creates broken code), it''s running > very, > very smoothly.One question I''ve been meaning to ask, and I haven''t had the time to check myself is if there are problems when using a 64bit domU kernel with modules and 32bit userland modutils in Debian or other distributions. Does a 32bit userland imply the need for static non-module kernels? -- Nicholas Lee http://stateless.geek.nz gpg 8072 4F86 EDCD 4FC1 18EF 5BDD 07B0 9597 6D58 D70C _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hello Nicholas,
I used xen 3.0.1 with 64-bit debian sarge for dom0, and several 64-
and 32-bit sarge domU''s. The domU kernel was 64-bit even for the
32-bit linux''es. Hardware is amd64 (venice) with 4GB memory.
This worked quite good for several applications that require 32-bit
linux. However I had no chance to get DB2(*) running in such a 32-bit
domU. The problem was that DB2 did not find any shared memory at all,
a "ipcs -l" did not show any shared memory limits in such a 32-bit
domU, but only something as:
------ Shared Memory Limits --------
------ Semaphore Limits --------
max number of arrays = 1024
max semaphores per array = 250
max semaphores system wide = 32000
max ops per semop call = 32
semaphore max value = 32767
------ Messages: Limits --------
max queues system wide = 1024
max size of message (bytes) = 8192
default max size of queue (bytes) = 16384
Shutting down such a 32-bit domU also most time resulted in a zombie.
I finally moved everything back to plain 32-bit (with PAE to make use
of all 4 GB memory).
I don''t know if this was fixed yet, or I maybe should have tried to
use a 32-bit kernel for the domU''s. I might give it another try as
soon as etch is stable.
--
Seneca
(*) DB2 is also available as 64-bit, however it will not work on
debian amd64 because it is not plain 64-bit but a mixture of 64-
and 32-bit programs. Same for Oracle btw.
You wrote at Freitag, 21. April 2006 01:36:
NL> On 4/12/06, Heiko Wundram <me+xen-users@modelnine.org>
wrote:>>
>> Something similar here: AMD64 with 4GB RAM running a 64-bit Gentoo
Dom0,
>> running 30 DomUs, which are mixed 32-bit Debian/SuSE/FC4/CentOS and
64-bit
>> Gentoo, but all with a 64-bit kernel for the DomU. If you
don''t choose
>> stupid
>> compiler-settings (beware of -Os, it creates broken code),
it''s running
>> very,
>> very smoothly.
NL> One question I''ve been meaning to ask, and I haven''t
had the time to check
NL> myself is if there are problems when using a 64bit domU kernel with
modules
NL> and 32bit userland modutils in Debian or other distributions.
NL> Does a 32bit userland imply the need for static non-module kernels?
NL> --
NL> Nicholas Lee
NL> http://stateless.geek.nz
NL> gpg 8072 4F86 EDCD 4FC1 18EF 5BDD 07B0 9597 6D58 D70C
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
Seneca wrote:> (*) DB2 is also available as 64-bit, however it will not work on > debian amd64 because it is not plain 64-bit but a mixture of 64- > and 32-bit programs. Same for Oracle btw. >Not directly related to Xen, but I don''t see why you couldn''t use the 64bit DB2. If debian amd64 does not provide 32 bit compatibility libs, perhaps you could try redhat/centos. -- Fajar _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hello Fajar, I guess that would have worked, and if this would be a production server I would have given centos a try. However this is a development server and I wanted everything on debian to ease maintenance. But I wonder if this shared memory issue in mixed 64- and 32-bit domains persists in xen 3.0.2-2. Could anybody with such a setup please enter "ipcs -l" in a 32-bit domU and post the result? -- Seneca You wrote at Freitag, 21. April 2006 09:54: FAN> Seneca wrote:>> (*) DB2 is also available as 64-bit, however it will not work on >> debian amd64 because it is not plain 64-bit but a mixture of 64- >> and 32-bit programs. Same for Oracle btw. >>FAN> Not directly related to Xen, but I don''t see why you couldn''t use the FAN> 64bit DB2. If debian amd64 does not provide 32 bit compatibility libs, FAN> perhaps you could try redhat/centos. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Seneca schrieb:> Hello Fajar, > > I guess that would have worked, and if this would be a production > server I would have given centos a try. However this is a development > server and I wanted everything on debian to ease maintenance. > > But I wonder if this shared memory issue in mixed 64- and 32-bit > domains persists in xen 3.0.2-2. Could anybody with such a setup > please enter "ipcs -l" in a 32-bit domU and post the result? >Running freshly compiled xen 3.0.2-2 with same x86_64 Dom0 and DomU Kernel 2.6.16.9. Dom0 is SuSE 10.0 (64-bit), this vm03 is Debian sarge (32-bit): vm03:~# uname -a Linux vm03.schenk.aix.de 2.6.16.9-xen #1 SMP Thu Apr 20 19:52:30 CEST 2006 x86_64 GNU/Linux vm03:~# ipcs -l ------ Shared Memory Limits -------- max number of segments = 4096 max seg size (kbytes) = 32768 max total shared memory (pages) = 2097152 min seg size (bytes) = 1 ------ Semaphore Limits -------- max number of arrays = 128 max semaphores per array = 250 max semaphores system wide = 32000 max ops per semop call = 32 semaphore max value = 32767 ------ Messages: Limits -------- max queues system wide = 16 max size of message (bytes) = 8192 default max size of queue (bytes) = 16384 -- __________________________________________________ Ralf Schenk fon (02 41) 9 91 21-0 fax (02 41) 9 91 21-59 rs@databay.de Databay AG Hüttenstraße 7 D-52068 Aachen www.databay.de Databay - einfach machen. _________________________________________________ _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users