You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(245) |
Nov
(321) |
Dec
(102) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(133) |
Feb
(365) |
Mar
(265) |
Apr
(152) |
May
(127) |
Jun
(205) |
Jul
(515) |
Aug
(449) |
Sep
(485) |
Oct
(553) |
Nov
(740) |
Dec
(640) |
2005 |
Jan
(1277) |
Feb
(1154) |
Mar
(1282) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Hari K. <har...@gm...> - 2005-03-24 23:43:58
|
Hello, I would like to export a directory to all my domains from domain0 by adding it to /etc/exports. The problem is nfs daemon seems to have problem starting up on my system. # /etc/init.d/nfs start Starting NFS services: [ OK ] Starting NFS quotas: [ OK ] Starting NFS daemon: [FAILED] Starting NFS mountd: [ OK ] When I inspect /var/log/messages, it says: nfsd[2696]: nfssvc: No such device Is there any known issues with nfs support on xen kernel? Or could it be a configuration issue? Thanks much! -Hari |
From: Ryan H. <ry...@us...> - 2005-03-24 23:17:25
|
* Ryan Harper <ry...@us...> [2005-03-24 15:59]: > * Keir Fraser <Kei...@cl...> [2005-03-24 15:50]: > > > > On 24 Mar 2005, at 15:50, Ryan Harper wrote: > > > > >* Ryan Harper <ry...@us...> [2005-03-23 10:32]: > > >>The latest (20050322) xen-unstable fails to boot dom0 when CONFIG_SMP > > >>is > > >>enabled. The last working snapshot was from 2005-03-18. I traced the > > >>problem to a dropped #ifdef CONFIG_SMP in pgtable-2level.h > > > > > >This is still broken in 20050324. Any reason not to apply this patch? > > > > It only fixed the symptom and not the root problem (broken TLB flushing > > in Xen). I've just checked in a proper fix. SMP domain0 is running okay > > for me now. > > Sorry for the impatience. I'll give it a test. Thanks. The patch works for me as well. Thanks Keir. Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 ry...@us... |
From: michal u. <mi...@an...> - 2005-03-24 22:38:59
|
On Thu, Mar 24, 2005 at 04:34:26PM -0600, Phil Brutsche wrote: > Ian Pratt wrote: > >>The machine is a PowerEdge 2850, the controller is a PERC 4e/Di. > > > > Is this the standard on-board SCSI controller? > > It's an embedded LSI Logic MegaRAID controller. > > I've heard that the stock firmware (v 513O) for this controller on the > Dell PowerEdge 2800/2850 is very buggy. > > I suggest that Michal upgrade the controller's firmware (to v 516A - the > latest and greatest) and try again. > > If that still doesn't fix it, then I suggest that Michal contact Dell's > technical support and get the machine repaired or replaced. > Hi, yes, I've got the latest version of the 516A firmware (got that from Dell a few days ago). I'm just running some tests now to try to get it to crash in order to answer Ian's previous questions... -michal |
From: Phil B. <ph...@br...> - 2005-03-24 22:34:33
|
Ian Pratt wrote: >>The machine is a PowerEdge 2850, the controller is a PERC 4e/Di. > > Is this the standard on-board SCSI controller? It's an embedded LSI Logic MegaRAID controller. I've heard that the stock firmware (v 513O) for this controller on the Dell PowerEdge 2800/2850 is very buggy. I suggest that Michal upgrade the controller's firmware (to v 516A - the latest and greatest) and try again. If that still doesn't fix it, then I suggest that Michal contact Dell's technical support and get the machine repaired or replaced. -- Phil Brutsche ph...@br... |
From: Ryan H. <ry...@us...> - 2005-03-24 21:59:59
|
* Keir Fraser <Kei...@cl...> [2005-03-24 15:50]: > > On 24 Mar 2005, at 15:50, Ryan Harper wrote: > > >* Ryan Harper <ry...@us...> [2005-03-23 10:32]: > >>The latest (20050322) xen-unstable fails to boot dom0 when CONFIG_SMP > >>is > >>enabled. The last working snapshot was from 2005-03-18. I traced the > >>problem to a dropped #ifdef CONFIG_SMP in pgtable-2level.h > > > >This is still broken in 20050324. Any reason not to apply this patch? > > It only fixed the symptom and not the root problem (broken TLB flushing > in Xen). I've just checked in a proper fix. SMP domain0 is running okay > for me now. Sorry for the impatience. I'll give it a test. Thanks. Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 ry...@us... |
From: Keir F. <Kei...@cl...> - 2005-03-24 21:49:39
|
On 24 Mar 2005, at 15:50, Ryan Harper wrote: > * Ryan Harper <ry...@us...> [2005-03-23 10:32]: >> The latest (20050322) xen-unstable fails to boot dom0 when CONFIG_SMP >> is >> enabled. The last working snapshot was from 2005-03-18. I traced the >> problem to a dropped #ifdef CONFIG_SMP in pgtable-2level.h > > This is still broken in 20050324. Any reason not to apply this patch? It only fixed the symptom and not the root problem (broken TLB flushing in Xen). I've just checked in a proper fix. SMP domain0 is running okay for me now. -- Keir |
From: Ian P. <m+I...@cl...> - 2005-03-24 21:45:51
|
> It hangs, solid. No ssh, dead to the network, console dead, etc. No > reboot... I've come back to a hung machine after a weekend, and it was > still hung.=20 >=20 > Once it hangs, I can't get anything on a console or anything. Nothing > makes it down to the logs, either, as far as I can tell. Please can you switch to a text console and then try an get it to hang. Hopefully something will come out.=20 Also, please can you add 'watchdog' to the Xen command line in grub.conf. =20 > The machine is a PowerEdge 2850, the controller is a PERC 4e/Di. Is this the standard on-board SCSI controller? Ian |
From: michal u. <mi...@an...> - 2005-03-24 21:43:14
|
On Thu, Mar 24, 2005 at 09:33:45PM -0000, Ian Pratt wrote: > > Sorry to bug the list again, but is anyone running xen on recent Dell > > hardware equipped with the PERC 4e/[SD]i controller? I've been having > > issues with random hangs, and I'm trying to narrow down the list of > > possible causes. > > That's worrying. > > When you say 'hangs', does the machine lock solid, or do non disk-bound > processes continue OK (e.g. if you have a running 'top' does it continue > to update?). Also, does the machine eventually reboot, or just hang. > > If you switch to a text console and run the 'find', do you see an Oops > message come out? > > What model of Dell machine is this? It hangs, solid. No ssh, dead to the network, console dead, etc. No reboot... I've come back to a hung machine after a weekend, and it was still hung. Once it hangs, I can't get anything on a console or anything. Nothing makes it down to the logs, either, as far as I can tell. The machine is a PowerEdge 2850, the controller is a PERC 4e/Di. -michal |
From: Ian P. <m+I...@cl...> - 2005-03-24 21:42:44
|
> [I believe steps 2 amd 3 will be done by executing=20 > xend start. I verified this by running 'brctl show'=20 > after I ran 'xend start'] >=20 > 4. Put up the bridge. > # ifconfig xen-br0 up >=20 > Now that I have the bridge up, I tried running=20 >=20 > ifup eth0 >=20 > to get an IP address. It's 'mybridge' you want to configure with dhcp, not eth0. You'll need to create an appropriate ifcfg-mybridge file then 'ifup mybridge'. Ian=20 |
From: Ian P. <m+I...@cl...> - 2005-03-24 21:33:53
|
> Sorry to bug the list again, but is anyone running xen on recent Dell=20 > hardware equipped with the PERC 4e/[SD]i controller? I've been having=20 > issues with random hangs, and I'm trying to narrow down the list of=20 > possible causes. That's worrying. When you say 'hangs', does the machine lock solid, or do non disk-bound processes continue OK (e.g. if you have a running 'top' does it continue to update?). Also, does the machine eventually reboot, or just hang. If you switch to a text console and run the 'find', do you see an Oops message come out? What model of Dell machine is this? Ian |
From: Bharadwaj Y. <bha...@hp...> - 2005-03-24 21:31:32
|
Apologies if this is trivial and an FAQ. Google search hasn't helped. I have been unsuccessful in getting eth0 interface up in dom0. My linux installation is FC3 and I get my address via DHCP. I am running Linux 2.6.11-xen0. I see the following steps recommended in the bridge-utils HOWTO page 1. Zero IP the interfaces. The bridge needs the network devices to be operational, but without TCP/IP running on them. # ifconfig eth0 0.0.0.0 2. Create the bridge interface. # brctl addbr mybridge 3. Add interfaces to the bridge. # brctl addif mybridge eth0 [I believe steps 2 amd 3 will be done by executing xend start. I verified this by running 'brctl show' after I ran 'xend start'] 4. Put up the bridge. # ifconfig xen-br0 up Now that I have the bridge up, I tried running ifup eth0 to get an IP address. I get the following: "Determining IP information for eth0...PING <my.dhcp.server.address> from <what-I-think.is-the-IP.address.I-was-assigned>: eth0" [usual ping statistics stuff] failed. I suspect I am close but not there. Can someone provide the nudge please? Thanks, Bharadwaj |
From: Christian L. <chr...@gm...> - 2005-03-24 21:24:33
|
On Thu, 24 Mar 2005 15:03:19 -0600, Hollis Blanchard <ho...@us...> wrote: > On Thursday 24 March 2005 14:40, Dan Magenheimer wrote: > > This second patch looks good to me, though I would prefer > > to change to '#include <asm/regs.h>' from 'struct xen_regs;' > > as xen_regs is #define'd to pt_regs on ia64 and the explicit > > use of struct xen_regs in a header could cause header ordering > > problems later. Will that work for ppc? > > Ah, sure... I was just trying to avoid extra dependency trees where possible. > Apparently it is not possible here. :) > > So that should be #include <public/xen.h> (which includes arch-*.h which > defines xen_regs). It looks like we may want to move ia64's #define to > arch-ia64.h ... Could you please include asm/regs.h or public/xen.h wherever you want to include keyhandler.h? Thanks. christian |
From: Kip M. <kip...@gm...> - 2005-03-24 21:22:13
|
# This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/23 18:27:49-08:00 km...@sh... # only bump tmpindex by NKPT-1 once # release sched lock on upcall # Signed-off-by: Kip Macy <km...@fs...> # # freebsd-5.3-xen-sparse/i386-xen/i386-xen/machdep.c # 2005/03/23 18:24:47-08:00 km...@sh... +0 -4 # remove extra bump of tmpindex # # freebsd-5.3-xen-sparse/i386-xen/i386-xen/evtchn.c # 2005/03/23 18:24:47-08:00 km...@sh... +7 -3 # release sched lock on upcall # diff -Nru a/freebsd-5.3-xen-sparse/i386-xen/i386-xen/evtchn.c b/freebsd-5.3-xen-sparse/i386-xen/i386-xen/evtchn.c --- a/freebsd-5.3-xen-sparse/i386-xen/i386-xen/evtchn.c 2005-03-24 13:19:58 -08:00 +++ b/freebsd-5.3-xen-sparse/i386-xen/i386-xen/evtchn.c 2005-03-24 13:19:58 -08:00 @@ -54,16 +54,16 @@ { unsigned long l1, l2; unsigned int l1i, l2i, port; - int irq; + int irq, owned; unsigned long flags; shared_info_t *s = HYPERVISOR_shared_info; vcpu_info_t *vcpu_info = &s->vcpu_data[smp_processor_id()]; local_irq_save(flags); - while ( s->vcpu_data[0].evtchn_upcall_pending ) + while ( vcpu_info->evtchn_upcall_pending ) { - s->vcpu_data[0].evtchn_upcall_pending = 0; + vcpu_info->evtchn_upcall_pending = 0; /* NB. No need for a barrier here -- XCHG is a barrier on x86. */ l1 = xen_xchg(&vcpu_info->evtchn_pending_sel, 0); while ( (l1i = ffs(l1)) != 0 ) @@ -78,12 +78,16 @@ l2 &= ~(1 << l2i); port = (l1i << 5) + l2i; + if ((owned = mtx_recursed(&sched_lock)) != 0) + mtx_unlock_spin_flags(&sched_lock, MTX_QUIET); if ( (irq = evtchn_to_irq[port]) != -1 ) { struct intsrc *isrc = intr_lookup_source(irq); intr_execute_handlers(isrc, frame); } else { evtchn_device_upcall(port); } + if (owned) + mtx_lock_spin_flags(&sched_lock, MTX_QUIET); } } } diff -Nru a/freebsd-5.3-xen-sparse/i386-xen/i386-xen/machdep.c b/freebsd-5.3-xen-sparse/i386-xen/i386-xen/machdep.c --- a/freebsd-5.3-xen-sparse/i386-xen/i386-xen/machdep.c 2005-03-24 13:19:58 -08:00 +++ b/freebsd-5.3-xen-sparse/i386-xen/i386-xen/machdep.c 2005-03-24 13:19:58 -08:00 @@ -1454,10 +1454,6 @@ for (i = 0; i < NKPT-1; i++, tmpindex++) xpq_queue_pt_update(IdlePTD + KPTDI + i + 1, xpmap_ptom((tmpindex << PAGE_SHIFT))| PG_M | PG_RW | PG_V | PG_A); tmpindex += NKPT-1; - - - - tmpindex += NKPT-1; PT_UPDATES_FLUSH(); HYPERVISOR_shared_info = (shared_info_t *)(KERNBASE + (tmpindex << PAGE_SHIFT)); |
From: Magenheimer, D. (HP L. F. Collins) <dan...@hp...> - 2005-03-24 21:17:19
|
arch-ia64.h doesn't declare/define struct xen_regs so this wouldn't work very well on ia64. I would prefer <asm/regs.h> (or even just leaving it as the forward struct reference). > -----Original Message----- > From: Hollis Blanchard [mailto:ho...@us...]=20 > Sent: Thursday, March 24, 2005 2:03 PM > To: xen...@li... > Cc: Magenheimer, Dan (HP Labs Fort Collins) > Subject: Re: [Xen-devel] Re: [patch] final header fixes >=20 > On Thursday 24 March 2005 14:40, Dan Magenheimer wrote: > > This second patch looks good to me, though I would prefer > > to change to '#include <asm/regs.h>' from 'struct xen_regs;' > > as xen_regs is #define'd to pt_regs on ia64 and the explicit > > use of struct xen_regs in a header could cause header ordering > > problems later. Will that work for ppc? >=20 > Ah, sure... I was just trying to avoid extra dependency trees=20 > where possible.=20 > Apparently it is not possible here. :) >=20 > So that should be #include <public/xen.h> (which includes=20 > arch-*.h which=20 > defines xen_regs). It looks like we may want to move ia64's=20 > #define to=20 > arch-ia64.h ... >=20 > --=20 > Hollis Blanchard > IBM Linux Technology Center >=20 |
From: Hollis B. <ho...@us...> - 2005-03-24 21:04:18
|
On Thursday 24 March 2005 14:40, Dan Magenheimer wrote: > This second patch looks good to me, though I would prefer > to change to '#include <asm/regs.h>' from 'struct xen_regs;' > as xen_regs is #define'd to pt_regs on ia64 and the explicit > use of struct xen_regs in a header could cause header ordering > problems later. Will that work for ppc? Ah, sure... I was just trying to avoid extra dependency trees where possible. Apparently it is not possible here. :) So that should be #include <public/xen.h> (which includes arch-*.h which defines xen_regs). It looks like we may want to move ia64's #define to arch-ia64.h ... -- Hollis Blanchard IBM Linux Technology Center |
From: michal u. <mi...@an...> - 2005-03-24 20:53:46
|
Hello all, Sorry to bug the list again, but is anyone running xen on recent Dell hardware equipped with the PERC 4e/[SD]i controller? I've been having issues with random hangs, and I'm trying to narrow down the list of possible causes. Symptom: moderate io causes my xen-running machine to lock hard. Doing something like "find /" does it everytime, but I've also had hangs while booting virtual domains, doing a dd, etc. It's happened in both domain0 and in other virtual domains. This hang during find does not occur when using a stock Debian (2.4.28) kernel nor a self-compiled 2.6.10 kernel (which is my first big clue that it might be a xen-related issue). I've consulted with Dell on this, and they recommended a firmware upgrade, but that did nothing for my particular problem. I'm running 2.6.10 in domain0, using the debian packages provided by Adam Heath. The driver I'm trying to use is the new megaraid driver, not the legacy one, which doesn't seem to recognize the raid controller at all. My first guess was flakey hardware, but testing with non-xen kernels makes me think otherwise. Does anyone have any ideas what I could try next? thanks, -michal urbanski |
From: Dan M. <dan...@hp...> - 2005-03-24 20:40:57
|
Sorry for the delay in comment... I was traveling and am a bit behind on email. This second patch looks good to me, though I would prefer to change to '#include <asm/regs.h>' from 'struct xen_regs;' as xen_regs is #define'd to pt_regs on ia64 and the explicit use of struct xen_regs in a header could cause header ordering problems later. Will that work for ppc? Dan |
From: Adam H. <do...@br...> - 2005-03-24 20:13:40
|
On Wed, 23 Mar 2005, Hollis Blanchard wrote: > On Wednesday 23 March 2005 14:48, Anthony Liguori wrote: > > Hollis Blanchard wrote: > > > > > >But I really don't like that for every command to recurse with (e.g. > > > clean), you must add more hackery to the Makefile. Your snippet has the > > > same problem (let's add "clean"...), and it seems all the Makefiles have > > > all the issues discussed in different places. > > > > > >Is there really no better way to solve this problem? > > > > The following works for me. You need a default rule or else make gets > > really confused but the wildcard rule will catch everything else. > > > > SUBDIRS=sub sub1 > > > > all: > > @for i in $(SUBDIRS); do \ > > $(MAKE) -C $$i $@; \ > > done > > > > %: > > @for i in $(SUBDIRS); do \ > > $(MAKE) -C $$i $@; \ > > done > > But the for loop was the original approach, and Adam described two problems > with it: > 1. errors in a sub-make will be ignored > 2. the sub-makes cannot be parallelized I've done fancy make stuff for years. It's what eventually made me write jmake(pure java implementation of most of gnu-make; just need to resolve the dependency tree). Hand-written parser, function/expression, implicit rules. It can currently parse the entire 2.6 kernel build system. I need to release it. |
From: Adam H. <do...@br...> - 2005-03-24 20:11:57
|
On Wed, 23 Mar 2005, Christian Limpach wrote: > On Tue, 22 Mar 2005 15:10:21 -0600, Jerone Young <jy...@us...> wrote: > > I cleaned up the top level makefile in the tools directory. No major > > changes. Except I have it so that ioemmu is compiled only with x86_32. > > I think the change below changes the behaviour: > > > +SUBDIRS := > > +SUBDIRS += check > ... > > -install: > > - $(MAKE) -C check > > - $(MAKE) -C libxutil install > ... > > +install: > > + @for subdir in $(SUBDIRS); do \ > > + $(MAKE) -C $$subdir $@ || exit -1; \ > > + done > > You're calling ``make -C check install'' while we want to call ``make > -C check''. See the comments in tools/check/Makefile why we want > this... > # Check this machine is OK for installing on. > # DO NOT use this check from 'make install' in the parent > # directory, as that target can be used to make an installable > # copy rather than actually installing. > > At least you didn't try to go down the insane "try to make everything > build in parallel" road, it might work for the tools but you need to > be careful to make sure that targets which other targets depend on get > built first. None of the fancy Makefile tricks which other people > have posted seem to take this into account :-( == install: check @whatever way people want to recurse check: $(MAKE) -C check # check is a real subdir, so we need to make it PHONY; otherwise, make assumes # it's uptodate, and the command won't be run. .PHONY: check == I originally didn't comment on this, as it wasn't my focus. But yes, if you are going to replace a set of rules, make certain they do the same thing after as they did before. |
From: Adam H. <do...@br...> - 2005-03-24 20:08:56
|
On Wed, 23 Mar 2005, Anthony Liguori wrote: > The following works for me. You need a default rule or else make gets > really confused but the wildcard rule will catch everything else. > > SUBDIRS=sub sub1 > > all: > @for i in $(SUBDIRS); do \ > $(MAKE) -C $$i $@; \ > done > > %: > @for i in $(SUBDIRS); do \ > $(MAKE) -C $$i $@; \ > done No, that won't work, as if the sub-makes fail, the shell loop doesn't stop(hint, use set -e). Also, it breaks -j. Please go back and reread the previous mails. |
From: Adam H. <do...@br...> - 2005-03-24 20:07:17
|
On Wed, 23 Mar 2005, Hollis Blanchard wrote: > On Wednesday 23 March 2005 12:01, Adam Heath wrote: > > install: $(patsubst %,install.%,$(SUBDIRS)) > > $(patsubst %,install.%,$(SUBDIRS)): install.%: CMD := install > > > > all: $(patsubst %,all.%,$(SUBDIRS)) > > $(patsubst %,all.%,$(SUBDIRS)): all.%: CMD := all > > > > $(foreach cmd,all install,$(patsubst %,$(cmd).%,$(SUBDIRS))): > > $(MAKE) -C $* $(CMD) > > The following is working for me and I think easier to read than the above: > == > CLEANDIRS := $(addprefix _clean_,$(SUBDIRS)) > > .PHONY: all clean $(SUBDIRS) $(CLEANDIRS) > > all: $(SUBDIRS) > clean: $(CLEANDIRS) > > $(CLEANDIRS): > $(MAKE) -C $(patsubst _clean_%,%,$@) clean > > $(SUBDIRS): > $(MAKE) -C $@ > == > > Well, I guess it's not very dissimilar after all. > > But I really don't like that for every command to recurse with (e.g. clean), > you must add more hackery to the Makefile. Your snippet has the same problem > (let's add "clean"...), and it seems all the Makefiles have all the issues > discussed in different places. > > Is there really no better way to solve this problem? == define subdir.command $(1)_targets := $$(addprefix $(1).,$$(SUBDIRS)) $(1): $$($(1)_targets) $$($(1)_targets): $(1).%: CMD := $(1) $(MAKE) -C $* $(CMD) endef $(eval subdir.command,install) $(eval subdir.command,clean) == I've not verified if the above works; ie, the quoting of $ in the multi-line variable. eval is a gnumake extension, so may not work elsewhere. |
From: Mark W. <ma...@cl...> - 2005-03-24 19:55:45
|
> I am considering using XEN to host "virtual dedicated servers" for a > few of my clients. Are there any security issues that would allow domU > (guestOS) admins access to dom0 No the aim is for domUs to have no more power to abuse dom0 than a separate physical machine would (i.e. they'd have to use some sort of network based attack, just like another machine would). > or global xend commands by default? I think the current default is to accept Xend commands anywhere (!). You can restrict this to only allow commands from localhost (i.e. from users local to dom0). This is a bit better, as long as you trust your dom0 users. You'll probably want to use some firewall rules in dom0 to isolate the Xend and Xfrd services appropriately. Cheers, Mark > If > so, is there anything I can do to lock it down so that only dom0 users > (root) would have access to dom0 and the xend commands? > > Thanks, > Brian > > > ------------------------------------------------------- > This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005 > Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows > Embedded(r) & Windows Mobile(tm) platforms, applications & content. > Register by 3/29 & save $300 > http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click > _______________________________________________ > Xen-devel mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xen-devel |
From: Anthony L. <ali...@us...> - 2005-03-24 19:48:52
|
On Thu, 2005-03-24 at 13:06, Tommi Virtanen wrote: > Ian Pratt wrote: > > For Xen 2.x, unix domain sockets would be too much of a pain to > > implement over Twisted. Kurt's approach gets us closer toward 'secure by > > default'. > > That just tells me you don't know twisted > (putting my "Twisted upstream developer" hat on..) > > Replace current reactor.listenTCP(port, protocolFactory) > with reactor.listenUNIX(path, protocolFactory). > If there's code that assumes TCP things (transport.getPeer() > to give IP addresses and ports etc), those may need to be fixed, > naturally. Thanks, I couldn't figure out why exporting the consoles over a domain socket wasn't working :-) Turns out we're using .getPeer(). I think perhaps we didn't use twisted as best as we could have so I agree with that it's going to be a fair bit of work. Regards, -- Anthony Liguori Linux Technology Center (LTC) - IBM Austin E-mail: ali...@us... Phone: (512) 838-1208 |
From: Xen U. <xe...@th...> - 2005-03-24 19:07:11
|
Hi List, I have a recent install of FC3 and am attempting to build xen from bk://xen.bkbits.com/xen-2.0.bk. Everything appears to build and install correctly. However, upon boot using the following stanza, it fails. title Fedora Core 3 (2.6.10-xen0) root (hd0,0) kernel /xen.gz dom0_mem=524288 noreboot module /vmlinuz-xen0 ro root=/dev/Main/Dom0 console=tty0 module /initrd-2.6.10-xen0.img /dev/Main/Dom0 is a logical volume on /dev/md0 (raid0) /initrd-2.6.10-xen0.img was built with (thanks, Nivedita) mkinitrd --omit-scsi-modules --omit-raid-modules \ initrd-2.6.10-xen0.img 2.6.10-xen0 Watching the boot process all seems in order, i.e. it recognizes all memory, drives, etc. Here's what's left on the console at failure. ... Freeing unused kernel memory RedHat nash version 4.1.18 starting Mounted /proc filesystem Mounting sysfs Creating /dev Starting udev Making device mapper control node Scanning logical volumes Reading all physical volumes. This may take a while . . . Activating logical volumes Making device nodes Creating root device Mounting root filesystem mount: error 6 mounting ext3 mount: error 2 mounting none Switching to new root switchroot: mount failed: 22 umount /initrd/dev failed: 2 Kernel panic - not syncing: Attempted to kill init! <0> Rebooting in 1 seconds.. Any insights? I'm afraid this might be one of those situations where I've looked at it so much that I'm seeing right through it :( TIA, Mike Wright :m) |
From: Tommi V. <tv...@tv...> - 2005-03-24 19:06:28
|
Ian Pratt wrote: > For Xen 2.x, unix domain sockets would be too much of a pain to > implement over Twisted. Kurt's approach gets us closer toward 'secure by > default'. That just tells me you don't know twisted (putting my "Twisted upstream developer" hat on..) Replace current reactor.listenTCP(port, protocolFactory) with reactor.listenUNIX(path, protocolFactory). If there's code that assumes TCP things (transport.getPeer() to give IP addresses and ports etc), those may need to be fixed, naturally. If you would use .tacs, as the recommended Twisted way of deplying server applications is, that would more like a configuration file change, done in /etc, as suits the admin. If you would use strports, that would be switching from string "8080" to string "unix:/path/to/socket". The actual protocol mechanics work identically. |