Menu
▾
▴
xen-devel — List for Xen developers
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: Anthony L. <ali...@us...> - 2005-03-25 19:06:45
|
Jerone Young wrote: >That's odd the file I did the diff from has the tabs just fine. Hmmm, >I'll redo it. > A lot of mail clients translate tabs into spaces when inlining patches. In general, it's better to attach patches (keeping a plain-text mime type of course) if you have such a mail client. Regards, Anthony Liguori |
|
From: Jerone Y. <jy...@us...> - 2005-03-25 19:04:50
|
On Fri, 2005-03-25 at 12:38 -0600, Adam Heath wrote: > Even here, the source file is missing the tab. Did your editor barf? Actually it was Evolution (my mail client) that did this I've attached the original patch. I guess it removed the tabs when I inserted the patch into the email. > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Xen-devel mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xen-devel > -- Jerone Young IBM Linux Technology Center jy...@us... 512-838-1157 (T/L: 678-1157) |
|
From: Xen U. <xe...@th...> - 2005-03-25 19:04:16
|
Hi list members, I have a fresh FC3 with fresh bk clone of xen-2.0.bk. It builds and installs without complaint. "/lib/tls" has been moved to "/lib/tls.disabled". My understanding is that in a stand-alone (no vms running) situation the performance difference between a standard kernel and a xen enabled kernel should be roughly the same. Is this correct? 2.6.10-xen0 boots with no errors, but the mouse seems jerky and slow to respond but is functional. Networking is up and functional. The drives are IDE in a raid0 using lvm. The m/b is typical budget x86 with 1GB ram and 1GHz Athlon. It has been in various uses without failure for a couple years. As a test I created a logical volume "Main/test" of 1G rw and formatted it with ext3. The inode creation part took perhaps 1 second but the journal creation took over 1 minute. I was able to have lunch (and do the dishes) in the time it took to format 18G. Reboot into 2.6.9 non-xen and try the same experiment and the entire process takes less than 2 seconds. I looked in /proc/interrupts but nothing there seems awry, i.e. no runaway counts. Does anyone have any idea what may be wrong or where I should look next? Thanks for any help, Mike Wright |
|
From: Jerone Y. <jy...@us...> - 2005-03-25 18:57:55
|
On Fri, 2005-03-25 at 12:38 -0600, Adam Heath wrote: > On Fri, 25 Mar 2005, Jerone Young wrote: > > > A lot of good discussion on the how the makefile should be for the past > > week. I waited to see how everything would pan out. So I left things > > simple and fixed up the patch. > > > > Signed-off-by: Jerone Young <jy...@us...> > > > > --- xen-unstable/tools/Makefile 2005-03-24 22:16:33.000000000 -0600 > > +++ xen-unstable.work/tools/Makefile 2005-03-25 10:59:12.000000000 -0600 > > @@ -1,37 +1,36 @@ > > +XEN_ROOT = ../ > > +include $(XEN_ROOT)/tools/Rules.mk > > > > -all: > > - $(MAKE) -C check > > - $(MAKE) -C libxutil > > - $(MAKE) -C libxc > > - $(MAKE) -C misc > > - $(MAKE) -C examples > > - $(MAKE) -C xentrace > > - $(MAKE) -C python > > - $(MAKE) -C xfrd > > - $(MAKE) -C xcs > > - $(MAKE) -C ioemu > > +SUBDIRS := > > +SUBDIRS += libxutil > > +SUBDIRS += libxc > > +SUBDIRS += misc > > +SUBDIRS += examples > > +SUBDIRS += xentrace > > +SUBDIRS += python > > +SUBDIRS += xfrd > > +SUBDIRS += xcs > > +SUBDIRS += ioemu > > + > > +.PHONY: all install clean check check_clean > > + > > +all: check > > + @for subdir in $(SUBDIRS); do \ > > + $(MAKE) -C $$subdir $@ || exit -1; \ > > + done > > How is this a valid makefile? Where's the tab? > > > > > -install: > > +install: check > > + @for subdir in $(SUBDIRS); do \ > > + $(MAKE) -C $$subdir $@ || exit -1; \ > > + done > > + > > +clean: check_clean > > + @for subdir in $(SUBDIRS); do \ > > + $(MAKE) -C $$subdir $@ || exit -1; \ > > + done > > + > > +check: > > $(MAKE) -C check > > - $(MAKE) -C libxutil install > > - $(MAKE) -C libxc install > > - $(MAKE) -C misc install > > - $(MAKE) -C examples install > > - $(MAKE) -C xentrace install > > - $(MAKE) -C python install > > - $(MAKE) -C xfrd install > > - $(MAKE) -C sv install > > - $(MAKE) -C xcs install > > - $(MAKE) -C ioemu install > > - > > -clean build: > > - $(MAKE) -C check $@ > > - $(MAKE) -C libxutil $@ > > - $(MAKE) -C libxc $@ > > - $(MAKE) -C misc $@ > > - $(MAKE) -C examples $@ > > - $(MAKE) -C xentrace $@ > > - $(MAKE) -C python $@ > > - $(MAKE) -C xfrd $@ > > - $(MAKE) -C xcs clean > > - $(MAKE) -C ioemu clean > > + > > +check_clean: > > + $(MAKE) -C check clean > > Even here, the source file is missing the tab. Did your editor barf? That's odd the file I did the diff from has the tabs just fine. Hmmm, I'll redo it. > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Xen-devel mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xen-devel > -- Jerone Young IBM Linux Technology Center jy...@us... 512-838-1157 (T/L: 678-1157) |
|
From: Adam H. <do...@br...> - 2005-03-25 18:38:45
|
On Fri, 25 Mar 2005, Jerone Young wrote: > A lot of good discussion on the how the makefile should be for the past > week. I waited to see how everything would pan out. So I left things > simple and fixed up the patch. > > Signed-off-by: Jerone Young <jy...@us...> > > --- xen-unstable/tools/Makefile 2005-03-24 22:16:33.000000000 -0600 > +++ xen-unstable.work/tools/Makefile 2005-03-25 10:59:12.000000000 -0600 > @@ -1,37 +1,36 @@ > +XEN_ROOT = ../ > +include $(XEN_ROOT)/tools/Rules.mk > > -all: > - $(MAKE) -C check > - $(MAKE) -C libxutil > - $(MAKE) -C libxc > - $(MAKE) -C misc > - $(MAKE) -C examples > - $(MAKE) -C xentrace > - $(MAKE) -C python > - $(MAKE) -C xfrd > - $(MAKE) -C xcs > - $(MAKE) -C ioemu > +SUBDIRS := > +SUBDIRS += libxutil > +SUBDIRS += libxc > +SUBDIRS += misc > +SUBDIRS += examples > +SUBDIRS += xentrace > +SUBDIRS += python > +SUBDIRS += xfrd > +SUBDIRS += xcs > +SUBDIRS += ioemu > + > +.PHONY: all install clean check check_clean > + > +all: check > + @for subdir in $(SUBDIRS); do \ > + $(MAKE) -C $$subdir $@ || exit -1; \ > + done How is this a valid makefile? Where's the tab? > > -install: > +install: check > + @for subdir in $(SUBDIRS); do \ > + $(MAKE) -C $$subdir $@ || exit -1; \ > + done > + > +clean: check_clean > + @for subdir in $(SUBDIRS); do \ > + $(MAKE) -C $$subdir $@ || exit -1; \ > + done > + > +check: > $(MAKE) -C check > - $(MAKE) -C libxutil install > - $(MAKE) -C libxc install > - $(MAKE) -C misc install > - $(MAKE) -C examples install > - $(MAKE) -C xentrace install > - $(MAKE) -C python install > - $(MAKE) -C xfrd install > - $(MAKE) -C sv install > - $(MAKE) -C xcs install > - $(MAKE) -C ioemu install > - > -clean build: > - $(MAKE) -C check $@ > - $(MAKE) -C libxutil $@ > - $(MAKE) -C libxc $@ > - $(MAKE) -C misc $@ > - $(MAKE) -C examples $@ > - $(MAKE) -C xentrace $@ > - $(MAKE) -C python $@ > - $(MAKE) -C xfrd $@ > - $(MAKE) -C xcs clean > - $(MAKE) -C ioemu clean > + > +check_clean: > + $(MAKE) -C check clean Even here, the source file is missing the tab. Did your editor barf? |
|
From: Jimi X. <ji...@wa...> - 2005-03-25 17:56:08
|
Add EM_PPC64 definition signed off by Jimi Xenidis jimix at watson.ibm.com |
|
From: Jerone Y. <jy...@us...> - 2005-03-25 17:13:56
|
A lot of good discussion on the how the makefile should be for the past week. I waited to see how everything would pan out. So I left things simple and fixed up the patch. Signed-off-by: Jerone Young <jy...@us...> --- xen-unstable/tools/Makefile 2005-03-24 22:16:33.000000000 -0600 +++ xen-unstable.work/tools/Makefile 2005-03-25 10:59:12.000000000 -0600 @@ -1,37 +1,36 @@ +XEN_ROOT = ../ +include $(XEN_ROOT)/tools/Rules.mk -all: - $(MAKE) -C check - $(MAKE) -C libxutil - $(MAKE) -C libxc - $(MAKE) -C misc - $(MAKE) -C examples - $(MAKE) -C xentrace - $(MAKE) -C python - $(MAKE) -C xfrd - $(MAKE) -C xcs - $(MAKE) -C ioemu +SUBDIRS := +SUBDIRS += libxutil +SUBDIRS += libxc +SUBDIRS += misc +SUBDIRS += examples +SUBDIRS += xentrace +SUBDIRS += python +SUBDIRS += xfrd +SUBDIRS += xcs +SUBDIRS += ioemu + +.PHONY: all install clean check check_clean + +all: check + @for subdir in $(SUBDIRS); do \ + $(MAKE) -C $$subdir $@ || exit -1; \ + done -install: +install: check + @for subdir in $(SUBDIRS); do \ + $(MAKE) -C $$subdir $@ || exit -1; \ + done + +clean: check_clean + @for subdir in $(SUBDIRS); do \ + $(MAKE) -C $$subdir $@ || exit -1; \ + done + +check: $(MAKE) -C check - $(MAKE) -C libxutil install - $(MAKE) -C libxc install - $(MAKE) -C misc install - $(MAKE) -C examples install - $(MAKE) -C xentrace install - $(MAKE) -C python install - $(MAKE) -C xfrd install - $(MAKE) -C sv install - $(MAKE) -C xcs install - $(MAKE) -C ioemu install - -clean build: - $(MAKE) -C check $@ - $(MAKE) -C libxutil $@ - $(MAKE) -C libxc $@ - $(MAKE) -C misc $@ - $(MAKE) -C examples $@ - $(MAKE) -C xentrace $@ - $(MAKE) -C python $@ - $(MAKE) -C xfrd $@ - $(MAKE) -C xcs clean - $(MAKE) -C ioemu clean + +check_clean: + $(MAKE) -C check clean -- Jerone Young IBM Linux Technology Center jy...@us... 512-838-1157 (T/L: 678-1157) |
|
From: Christopher S. A. <ca...@th...> - 2005-03-25 17:09:30
|
Using stable (2.05) tools and kernel, dom0 is CentOS 4.
# xm sysrq mydomain s
Error: Internal Server Error
(sorry for the word-wrapping)
==> /var/log/xend-debug.log <==
{'key': 115}
Traceback (most recent call last):
File "/usr/lib/python2.3/site-packages/twisted/protocols/basic.py", line 229, in
dataReceived
return self.rawDataReceived(data)
File "/usr/lib/python2.3/site-packages/twisted/protocols/http.py", line 1015, in
rawDataReceived
self.allContentReceived()
File "/usr/lib/python2.3/site-packages/twisted/protocols/http.py", line 1006, in
allContentReceived
req.requestReceived(command, path, version)
File "/usr/lib/python2.3/site-packages/twisted/protocols/http.py", line 557, in
requestReceived
self.process()
--- <exception caught here> ---
File "/usr/lib/python2.3/site-packages/twisted/web/server.py", line 165, in process
self.render(resrc)
File "/usr/lib/python2.3/site-packages/twisted/web/server.py", line 172, in render
body = resrc.render(self)
File "/usr/lib/python2.3/site-packages/twisted/web/resource.py", line 201, in
render
return m(request)
File "/usr/lib/python/xen/xend/server/SrvDomain.py", line 197, in render_POST
return self.perform(req)
File "/usr/lib/python/xen/xend/server/SrvBase.py", line 103, in perform
return self._perform(op, op_method, req)
File "/usr/lib/python/xen/xend/server/SrvBase.py", line 109, in _perform
return self._perform_err(err, op, req)
File "/usr/lib/python/xen/xend/server/SrvBase.py", line 107, in _perform
val = op_method(op, req)
File "/usr/lib/python/xen/xend/server/SrvDomain.py", line 52, in op_shutdown
val = fn(req.args, {'dom': self.dom.id})
File "/usr/lib/python/xen/xend/Args.py", line 140, in __call__
return self.call_with_form_args(self.fn, fargs, xargs=xargs)
File "/usr/lib/python/xen/xend/Args.py", line 116, in call_with_form_args
return fn(*params, **keys)
File "/usr/lib/python/xen/xend/XendDomain.py", line 477, in domain_shutdown
val = xend.domain_shutdown(dominfo.id, reason, key)
File "/usr/lib/python/xen/xend/server/SrvDaemon.py", line 724, in domain_shutdown
ctrl.shutdown(reason, key)
File "/usr/lib/python/xen/xend/server/domain.py", line 52, in shutdown
self.writeRequest(packMsg(msgtype, extra))
File "/usr/lib/python/xen/xend/server/messages.py", line 274, in packMsg
msg = xu.message(major, minor, msgid, args)
exceptions.TypeError: payload contains bad items
-Chris
|
|
From: Hollis B. <ho...@us...> - 2005-03-25 16:59:39
|
On Thu, 2005-03-24 at 13:17 -0800, Magenheimer, Dan (HP Labs Fort Collins) wrote: > 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). That's why I suggested moving the define to arch-ia64.h. Let me put it this way... ia64: asm/regs.h x86_32: public/xen.h x86_64: public/xen.h ppc64 will follow x86: public/xen.h Why should ia64 be different? Won't it make all of our lives easier if all the ports define structures in asm header files of the same name? -- Hollis Blanchard IBM Linux Technology Center |
|
From: Bharadwaj Y. <bha...@hp...> - 2005-03-25 16:56:17
|
Hi Ian, Thanks for your reply. However, I am still unable to get my network interface up in dom0. Here is what I did: I created a /etc/sysconfig/network-scripts/ifcfg-xen-br0 as you suggested. # more /etc/sysconfig/network-scripts/ifcfg-xen-br0 DEVICE=xen-br0 BOOTPROTO=dhcp ONBOOT=no TYPE=Ethernet DHCP_HOSTNAME=<myhostname> USERCTL=no PEERDNS=yes IPV6INIT=no [I also needed to modify /etc/sysconfig/network-scripts/network-functions so that the device xen-br0 is not picked as xen but as xen-br0.] Anyway, once dom0 booted, I do the following : # ifconfig eth0 0.0.0.0 up # xend start # ifup xen-br0 I see dhclient running (ps) but I get ======= Determining IP information for xen-br0... xen-br0 failed ====== What am I missing? I verified that eth0 interface would come up as expected and I get an IP address when booted with standard FC3 Linux kernel. Thanks for your help once again, Bharadwaj On Thu, Mar 24, 2005 at 09:42:44PM -0000, Ian Pratt wrote: > > [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. > > 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 > |
|
From: Hollis B. <ho...@us...> - 2005-03-25 16:25:16
|
On Thu, 2005-03-24 at 21:24 +0000, Christian Limpach wrote: > 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. That works great, until somebody other than me includes or modifies keyhandler.h (or any of the other headers we've been talking about). I guess I don't see the difficulty in making sure you include what you use...? -- Hollis Blanchard IBM Linux Technology Center |
|
From: joe <to...@fr...> - 2005-03-25 13:53:50
|
hi i am a complete newbie to xen, and i have still a problem with hda(hdc): lost interrupt coming from the 2.6.10-xen0 kernel on an asrock k7s8x board with an additional promise 100 controller(doesn't get recognized anyway) an amd athlon 2400+ and 512 mb ram. an ideas? regards toby |
|
From: Keir F. <Kei...@cl...> - 2005-03-25 13:26:02
|
On 25 Mar 2005, at 12:53, neo anderson wrote: > lately i download xen from www.cl.cam.ac.uk, yet > encountered problem when building from the source. its > version is xen-2.0.5-src.tgz (downloaded from > http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads/xen-2.0.5- > src.tgz). > i use debian 3.0 rx version with kernel manually > updated to 2.6.9; in which gcc version 2.95.4; make > 3.7.9. > the message reports as follow. how to solve it? i > appreciate it sincerely. > jason You need to use a newer gcc, preferably 3.2 or above. -- Keir |
|
From: neo a. <fre...@ya...> - 2005-03-25 12:54:07
|
hi, lately i download xen from www.cl.cam.ac.uk, yet encountered problem when building from the source. its version is xen-2.0.5-src.tgz (downloaded from http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads/xen-2.0.5-src.tgz). i use debian 3.0 rx version with kernel manually updated to 2.6.9; in which gcc version 2.95.4; make 3.7.9. the message reports as follow. how to solve it? i appreciate it sincerely. jason =============== messages ==========beg make[3]: curl-config: Command not found make[3]: Entering directory `/root/xen/xen-2.0/tools/xfrd' __ __ ____ ___ ____ \ \/ /___ _ __ |___ \ / _ \ | ___| \ // _ \ '_ \ __) || | | ||___ \ / \ __/ | | | / __/ | |_| | ___) | /_/\_\___|_| |_| |_____(_)___(_)____/ cc1: Invalid option `32' cc1: warnings being treated as errors In file included from /root/xen/xen-2.0/xen/include/xen/spinlock.h:5, from /root/xen/xen-2.0/xen/include/xen/sched.h:8, from x86_32/asm-offsets.c:7: /root/xen/xen-2.0/xen/include/asm/system.h:28: warning: `always_inline' attribute directive ignored /root/xen/xen-2.0/xen/include/asm/system.h:75: warning: `always_inline' attribute directive ignored In file included from /root/xen/xen-2.0/xen/include/asm/string.h:4, from /root/xen/xen-2.0/xen/include/xen/string.h:22, from /root/xen/xen-2.0/xen/include/xen/lib.h:6, from /root/xen/xen-2.0/xen/include/asm/spinlock.h:5, from /root/xen/xen-2.0/xen/include/xen/spinlock.h:39, from /root/xen/xen-2.0/xen/include/xen/sched.h:8, from x86_32/asm-offsets.c:7: /root/xen/xen-2.0/xen/include/asm/x86_32/string.h:210: warning: `always_inline' attribute directive ignored /root/xen/xen-2.0/xen/include/asm/x86_32/string.h:277: warning: `always_inline' attribute directive ignored /root/xen/xen-2.0/xen/include/asm/x86_32/string.h:415: warning: `always_inline' attribute directive ignored In file included from /root/xen/xen-2.0/xen/include/asm/uaccess.h:8, from /root/xen/xen-2.0/xen/include/xen/sched.h:129, from x86_32/asm-offsets.c:7: /root/xen/xen-2.0/xen/include/asm/x86_32/uaccess.h:319: warning: `always_inline' attribute directive ignored /root/xen/xen-2.0/xen/include/asm/x86_32/uaccess.h:357: warning: `always_inline' attribute directive ignored In file included from x86_32/asm-offsets.c:7: /root/xen/xen-2.0/xen/include/xen/sched.h:149: warning: `always_inline' attribute directive ignored make[3]: *** [asm-offsets.s] Error 1 make[2]: *** [/root/xen/xen-2.0/xen/xen] Error 2 make[1]: *** [xen] Error 2 make: *** [world] Error 2 ===============message ==========end Send instant messages to your online friends http://uk.messenger.yahoo.com |
|
From: Tupshin H. <tu...@tu...> - 2005-03-25 11:47:25
|
Ian Pratt wrote: > >We have a trivial patch to NTPL glibc that make it "xen-friendly", >providing glibc is built with the "-mno-tls-direct-seg-refs" option to >gcc. > >It's currently undergoing testing, and I expect we'll check it in to the >repo later this week. > >Ian > > > How's this patch coming. I'm trying to get a gentoo domU going and I would love to give this a try. -Tupshin |
|
From: Marius K. <Ma...@Ka...> - 2005-03-25 11:11:09
|
Ok heres some more info:
currently there are multiple domains up and running perfectly. i'm on dom0
*wilde root 0 # xm list
(111, 'Connection refused')
Error: Error connecting to xend, is xend running?*
check if it's running:
*wilde root 0 # ps |grep xend
root 13347 0.0 0.3 1436 404 pts/0 D+ 11:57 0:00 grep xend
wilde root 0 # ps |grep xfrd
root 26122 0.0 0.3 3252 464 ? S Mar16 0:00 xfrd
*
cleared the logs:
*wilde root 0 # cat /var/log/xend.log /var/log/xend-debug.log
wilde root 0 #
*
stopping xend (just to make sure):
*wilde root 0 # /etc/init.d/xend stop
wilde root 0 # cat /var/log/xend.log /var/log/xend-debug.log
wilde root 0 #
*
starting xend:
*wilde root 0 # /etc/init.d/xend start
.........
wilde root 3 #
*
(exit status 3, takes about 5 seconds of time-out-time)
see what is runnning:
*wilde root 0 # ps |grep xend
root 13469 0.0 0.3 1436 472 pts/0 R+ 12:03 0:00 grep xend
wilde root 0 # ps |grep xfr
root 13420 0.0 0.6 3048 792 ? S 12:02 0:00 xfrd
root 13471 0.0 0.3 1436 472 pts/0 R+ 12:04 0:00 grep xfr
wilde root 0 # ps |grep xcs
root 13477 0.0 0.3 1436 472 pts/0 R+ 12:04 0:00 grep xcs
*
So only xfrd has started. lets see what is in the logs:
*wilde root 1 # cat /var/log/xend.log
[2005-03-25 12:02:45 xend] INFO (SrvDaemon:610) Xend Daemon started
*
( i wish :S )
*wilde root 0 # cat /var/log/xend-debug.log
network start bridge=xen-br0 netdev=eth0 antispoof=yes
Traceback (most recent call last):
File "/usr/sbin/xend", line 121, in ?
sys.exit(main())
File "/usr/sbin/xend", line 107, in main
return daemon.start()
File "/usr/lib/python/xen/xend/server/SrvDaemon.py", line 525, in start
self.run()
File "/usr/lib/python/xen/xend/server/SrvDaemon.py", line 615, in run
SrvServer.create(bridge=1)
File "/usr/lib/python/xen/xend/server/SrvServer.py", line 47, in create
xend = SrvRoot()
File "/usr/lib/python/xen/xend/server/SrvRoot.py", line 29, in __init__
self.get(name)
File "/usr/lib/python/xen/xend/server/SrvDir.py", line 69, in get
val = val.getobj()
File "/usr/lib/python/xen/xend/server/SrvDir.py", line 39, in getobj
self.obj = klassobj()
File "/usr/lib/python/xen/xend/server/SrvDomainDir.py", line 25, in
__init__
self.xd = XendDomain.instance()
File "/usr/lib/python/xen/xend/XendDomain.py", line 798, in instance
inst = XendDomain()
File "/usr/lib/python/xen/xend/XendDomain.py", line 65, in __init__
self.initial_refresh()
File "/usr/lib/python/xen/xend/XendDomain.py", line 153, in
initial_refresh
d_dom = self._new_domain(config, doms[domid])
File "/usr/lib/python/xen/xend/XendDomain.py", line 188, in _new_domain
deferred = XendDomainInfo.vm_recreate(savedinfo, info)
File "/usr/lib/python/xen/xend/XendDomainInfo.py", line 218, in
vm_recreate
d = vm.construct(config)
File "/usr/lib/python/xen/xend/XendDomainInfo.py", line 453, in construct
self.construct_image()
File "/usr/lib/python/xen/xend/XendDomainInfo.py", line 480, in
construct_image
image_handler(self, image)
File "/usr/lib/python/xen/xend/XendDomainInfo.py", line 1065, in
vm_image_linux
vm.create_domain("linux", kernel, ramdisk, cmdline)
File "/usr/lib/python/xen/xend/XendDomainInfo.py", line 757, in
create_domain
self.create_channel()
File "/usr/lib/python/xen/xend/XendDomainInfo.py", line 782, in
create_channel
remote_port=remote)
File "/usr/lib/python/xen/xend/server/SrvDaemon.py", line 660, in
createDomChannel
remote_port=remote_port)
File "/usr/lib/python/xen/xend/server/channel.py", line 59, in domChannel
remote_port=remote_port)
File "/usr/lib/python/xen/xend/server/channel.py", line 229, in __init__
remote_port=remote_port)
File "/usr/lib/python/xen/xend/server/channel.py", line 113, in createPort
remote_port=int(remote_port))
xen.lowlevel.xu.PortError: Failed to map domain control interface
*
So there is the problem i guess. But i don't know what it means or how i
should fix it. Any ideas ?
Ian Pratt wrote:
>
>
>
>>Hi,
>>Every now and then xend seems to fail, the domains keep running but
>>control is lost completely.
>>A restart seems not possible. The logfile says xend restarts but the
>>only thing that restarts is xfrd binding on port 8002.
>>The only way to get control back seems to be to reboot the machine,
>>rebooting all of the client domains too wich is a *bad thing* for our
>>clients.
>>Is there any way to get control back?
>>Is anyone working on the problem is there a patch or even a
>>know cause??
>>Are there any steps i can take (or NOT take) to prevent this
>>from happening?
>>
>>
>
>You could try 'xend stop' and then kill 'xcs' manually, then
>'xend start'.
>
>You'll need to give us more help to debug the actual problem your
>experiencing.
>
>Ian
>
>
|
|
From: Ian P. <m+I...@cl...> - 2005-03-25 10:53:41
|
> > The intention is to have a shared memory bitmap frame buffer,=20 > > with a 'side channel' into which information about which=20 > > rectangles of the screen have been blited, filled, copied etc=20 > > can optionally be sent. > >=20 > > In dom0 we can use vnclib to export the disaply over the=20 > > network (over SSL) if required, or render it on the local X server. >=20 > Being new to Xen, I might be missing something obvious, but what's the > advantage of doing this VNC stuff in dom0? Why not do it in domU? Doing it in domU works fine, but isn't tranparent to the guest. =20 > Would it be feasible to have dom0 manage the VBE framebuffer=20 > (just about any > graphics card is VBE-compliant these days)? Dom0 would map=20 > the frame buffer > into the "foreground" domain, so the guest could write directly to the > hardware frame buffer. When another domain is brought to the=20 > foreground, > dom0 would copy the bits from the frame buffer to a shadow=20 > memory area, map > that memory area in place of the frame buffer in the domain which was > previously foreground and give access to the hardware frame=20 > buffer to the > new foreground domain (after copying the bits from its shadow=20 > frame buffer). This works fine for full-screen desktop use, but you do have to 'swizzle' the framebuffer for normal ram when another domain owns the display. If all the heads are running X, you can probably just use the SIGUSR1 support that's used for virutal consoles and let X take care of it. If you want to share a framebuffer in anything other than full screen (and care about protection), you need some proper virtualization. Ian |
|
From: Ge v. G. <gv...@re...> - 2005-03-25 10:44:38
|
> From: Ian Pratt >=20 > The intention is to have a shared memory bitmap frame buffer,=20 > with a 'side channel' into which information about which=20 > rectangles of the screen have been blited, filled, copied etc=20 > can optionally be sent. >=20 > In dom0 we can use vnclib to export the disaply over the=20 > network (over SSL) if required, or render it on the local X server. Being new to Xen, I might be missing something obvious, but what's the advantage of doing this VNC stuff in dom0? Why not do it in domU? Would it be feasible to have dom0 manage the VBE framebuffer (just about = any graphics card is VBE-compliant these days)? Dom0 would map the frame = buffer into the "foreground" domain, so the guest could write directly to the hardware frame buffer. When another domain is brought to the foreground, dom0 would copy the bits from the frame buffer to a shadow memory area, = map that memory area in place of the frame buffer in the domain which was previously foreground and give access to the hardware frame buffer to = the new foreground domain (after copying the bits from its shadow frame = buffer). > Any volunteers? ReactOS/Windows without GUI is, uhhhm, icky, so I'm definitely = interested in this. Just not right now, need to get ReactOS up and running first. G=E9 van Geldorp. |
|
From: Ian P. <m+I...@cl...> - 2005-03-25 09:56:24
|
=20 > Hi, > Every now and then xend seems to fail, the domains keep running but=20 > control is lost completely. > A restart seems not possible. The logfile says xend restarts but the=20 > only thing that restarts is xfrd binding on port 8002. > The only way to get control back seems to be to reboot the machine,=20 > rebooting all of the client domains too wich is a *bad thing* for our=20 > clients. > Is there any way to get control back? > Is anyone working on the problem is there a patch or even a=20 > know cause?? > Are there any steps i can take (or NOT take) to prevent this=20 > from happening? You could try 'xend stop' and then kill 'xcs' manually, then=20 'xend start'. You'll need to give us more help to debug the actual problem your experiencing. Ian |
|
From: Ian P. <m+I...@cl...> - 2005-03-25 09:22:00
|
> One thing I think xen could do with (if it isn't there=20 > already) is some sort of virtual framebuffer like with disk=20 > and network. Dom0 could provide the backend of the virtual=20 > framebuffer (on virtual consoles or inside X windows or=20 > whatever), and the other domains could make use of the=20 > exported framebuffers. It wouldn't be great for performance,=20 > but would provide a simple interface to the other domains,=20 > and be reasonably migratable. There's a plan for this:=20 The intention is to have a shared memory bitmap frame buffer, with a = 'side channel' into which information about which rectangles of the = screen have been blited, filled, copied etc can optionally be sent. In dom0 we can use vnclib to export the disaply over the network (over = SSL) if required, or render it on the local X server. Any volunteers? Ian=20 > > -----Original Message----- > > From: xen...@li... [mailto:xen-devel- > > ad...@li...] On Behalf Of Ge van Geldorp > > Sent: Friday, 25 March 2005 02:52 > > To: 'ReactOS Development List'; xen...@li... > > Subject: [Xen-devel] Xen port of ReactOS > >=20 > > Hello, > >=20 > > After doing some research, I've decided to go ahead and=20 > start a port of > > ReactOS to Xen. For those in the Xen community not familiar=20 > with ReactOS: > > it's an open-source (GPL) re-implementation of the Microsoft Windows > > NT-based line of operating systems, aiming to provide=20 > binary compatibility > > for both applications and drivers > > (http://www.reactos.com). For those in the ReactOS=20 > community not familiar > > with Xen: it's an open-source (GPL) virtual machine monitor=20 > that supports > > execution of multiple guest operating systems with=20 > unprecedented levels of > > performance and resource isolation > > (http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html). > >=20 > > Initially I'll focus on getting ReactOS running as a guest=20 > OS. This should > > benefit ReactOS primarily, since this will make it possible=20 > to develop > > large > > parts of ReactOS (everything except for hardware drivers=20 > and some low- > > level > > memory management) inside Xen. It will also give ReactOS=20 > access to some > > hardware not natively supported yet (by using the Linux driver). The > > benefit > > for Xen at this stage would be the development of ReactOS=20 > device drivers > > for > > interfacing > > with Xen, which could also be used for a Windows XP port.=20 > On the longer > > term, I see no reason why ReactOS couldn't function as a=20 > driver domain. As > > driver compatibility improves in ReactOS, this could=20 > provide Xen guests > > access to hardware for which the manufacturer provides only Windows > > drivers > > (due to Xens nature, not every driver > > could be used this way, but I bet a large percentage of the=20 > drivers depend > > on the kernel to do the really low-level stuff). > > All in all, it seems a win-win proposition for both=20 > projects. And even > > more > > importantly, I think it's a cool project :-) > >=20 > > I've made a branch in ReactOS svn,=20 > svn://svn.reactos.com/branches/xen, for > > this port. Of course, the goal is to merge the changes into trunk > > eventually. I expect the port to take at least a few=20 > months, my initial > > feeling is that it should be done by the end of the year=20 > (there's lots of > > other stuff in ReactOS I want to work on too). The wiki page at > > http://wiki.reactos.com/Xen_port will be used to keep track=20 > of progress. > > The > > game plan is just start working from the boot code, until a=20 > problem is > > hit. > > Fix that problem and continue until the next problem. > >=20 > > Any support and help from the Xen and ReactOS communities=20 > are of course > > greatly appreciated. > >=20 > > G=E9 van Geldorp. > >=20 > >=20 > >=20 > > ------------------------------------------------------- > > This SF.net email is sponsored by Microsoft Mobile &=20 > Embedded DevCon 2005 > > Attend MEDC 2005 May 9-12 in Vegas. Learn more about the=20 > latest Windows > > Embedded(r) & Windows Mobile(tm) platforms, applications & content. > > Register > > by 3/29 & save $300=20 > http://ads.osdn.com/?ad_idh83&alloc_id=15149&op=3Dick > > _______________________________________________ > > Xen-devel mailing list > > Xen...@li... > > https://lists.sourceforge.net/lists/listinfo/xen-devel >=20 >=20 >=20 > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from=20 > real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dick > _______________________________________________ > Xen-devel mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xen-devel >=20 |
|
From: Marius K. <Ma...@Ka...> - 2005-03-25 08:38:26
|
Hi, Every now and then xend seems to fail, the domains keep running but control is lost completely. A restart seems not possible. The logfile says xend restarts but the only thing that restarts is xfrd binding on port 8002. The only way to get control back seems to be to reboot the machine, rebooting all of the client domains too wich is a *bad thing* for our clients. Is there any way to get control back? Is anyone working on the problem is there a patch or even a know cause?? Are there any steps i can take (or NOT take) to prevent this from happening? Regards Marius Karthaus |
|
From: James H. <jam...@be...> - 2005-03-25 04:31:24
|
Fwiw, I think a ReactOS port would be very useful to both projects. One thing I think xen could do with (if it isn't there already) is some = sort of virtual framebuffer like with disk and network. Dom0 could = provide the backend of the virtual framebuffer (on virtual consoles or = inside X windows or whatever), and the other domains could make use of = the exported framebuffers. It wouldn't be great for performance, but = would provide a simple interface to the other domains, and be reasonably = migratable. James > -----Original Message----- > From: xen...@li... [mailto:xen-devel- > ad...@li...] On Behalf Of Ge van Geldorp > Sent: Friday, 25 March 2005 02:52 > To: 'ReactOS Development List'; xen...@li... > Subject: [Xen-devel] Xen port of ReactOS >=20 > Hello, >=20 > After doing some research, I've decided to go ahead and start a port = of > ReactOS to Xen. For those in the Xen community not familiar with = ReactOS: > it's an open-source (GPL) re-implementation of the Microsoft Windows > NT-based line of operating systems, aiming to provide binary = compatibility > for both applications and drivers > (http://www.reactos.com). For those in the ReactOS community not = familiar > with Xen: it's an open-source (GPL) virtual machine monitor that = supports > execution of multiple guest operating systems with unprecedented = levels of > performance and resource isolation > (http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html). >=20 > Initially I'll focus on getting ReactOS running as a guest OS. This = should > benefit ReactOS primarily, since this will make it possible to develop > large > parts of ReactOS (everything except for hardware drivers and some low- > level > memory management) inside Xen. It will also give ReactOS access to = some > hardware not natively supported yet (by using the Linux driver). The > benefit > for Xen at this stage would be the development of ReactOS device = drivers > for > interfacing > with Xen, which could also be used for a Windows XP port. On the = longer > term, I see no reason why ReactOS couldn't function as a driver = domain. As > driver compatibility improves in ReactOS, this could provide Xen = guests > access to hardware for which the manufacturer provides only Windows > drivers > (due to Xens nature, not every driver > could be used this way, but I bet a large percentage of the drivers = depend > on the kernel to do the really low-level stuff). > All in all, it seems a win-win proposition for both projects. And even > more > importantly, I think it's a cool project :-) >=20 > I've made a branch in ReactOS svn, svn://svn.reactos.com/branches/xen, = for > this port. Of course, the goal is to merge the changes into trunk > eventually. I expect the port to take at least a few months, my = initial > feeling is that it should be done by the end of the year (there's lots = of > other stuff in ReactOS I want to work on too). The wiki page at > http://wiki.reactos.com/Xen_port will be used to keep track of = progress. > The > game plan is just start working from the boot code, until a problem is > hit. > Fix that problem and continue until the next problem. >=20 > Any support and help from the Xen and ReactOS communities are of = course > greatly appreciated. >=20 > G=E9 van Geldorp. >=20 >=20 >=20 > ------------------------------------------------------- > 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_idh83&alloc_id=15149&op=3Dick > _______________________________________________ > Xen-devel mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xen-devel |
|
From: Xin Z. <zh...@ee...> - 2005-03-25 03:51:10
|
My nfs works fine. Several potential issues: 1. Did you enable NFS support when compiling the kernel? 2. Did you compile nfs as a kernel module? If so, did you do make modules modules_install? If not, maybe your NFS daemon is not built or installed to /lib/modules 3. There is something wrong in portmap, pls make sure that portmap is started right. good luck! Xin On Thu, 24 Mar 2005, Hari Kodungallur wrote: > 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 > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Xen-devel mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xen-devel > |
|
From: sada <sa...@pr...> - 2005-03-25 02:59:38
|
It was my mistake and I fix my image and work fine now (just because of my fc3.img dosen't have proper setting. Coparering mine and the one you Thanks Fajar > Do I have to do some special Setting for connecting xm from Outside? sada <sa...@pr...> |
|
From: Ian P. <m+I...@cl...> - 2005-03-25 00:04:12
|
=20 NFS servers on Xen work just fine. Our default kernel has the nfs server built in, but as a module. Are you sure you've installed the modules OK? CONFIG_NFSD=3Dm CONFIG_NFSD_V3=3Dy # CONFIG_NFSD_V4 is not set CONFIG_NFSD_TCP=3Dy Also, are you sure you're starting portmap etc? Ian > 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. >=20 > # /etc/init.d/nfs start > Starting NFS services: [ OK ] > Starting NFS quotas: [ OK ] > Starting NFS daemon: [FAILED] > Starting NFS mountd: [ OK ] >=20 > When I inspect /var/log/messages, it says: > nfsd[2696]: nfssvc: No such device >=20 > Is there any known issues with nfs support on xen kernel? Or could it > be a configuration issue? >=20 > Thanks much! > -Hari >=20 >=20 > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from=20 > real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick > _______________________________________________ > Xen-devel mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xen-devel >=20 |
55 messages has been excluded from this view by a project administrator.
