Bugzilla – Bug 116893
yast2 xen modules creates unbootable xen environment
Last modified: 2006-02-10 21:52:08 UTC
I must admit I'm somewhat of a newbie to Xen. The Xen entry in grub assigns all available memory to domain0, which the module complained about. I rebooted with dom0_mem=256000 to allow other domains some memory. When I used the yast2 xen module to create an environment, it proceeded in a manner which i can only assume meant success (there were no errors presented). When I tried starting the vm with "xm create domain1", the creation appeared to have succeeded, but domain never actually started. I'll attach my xend.log and y2logs.tgz
Created attachment 49850 [details] xend.log
Created attachment 49851 [details] xend-debug.log
Created attachment 49852 [details] y2logs.tgz
y2log contain this error message: xterm command: /usr/bin/xterm -T "XEN - domain1" -e /usr/sbin/xm create -c /etc/xen/domain1 sh: /usr/bin/xterm: No such file or directory It seems that xterm package is not installed. Please install xterm package and try it again. Or you can try to use command '/usr/sbin/xm create -c /etc/xen/domain1' to start the domain manually from any terminal. Which package selection did you choose? Or did you manually deselected xterm package?
I chose "Other->text based system" in the KDE/Gnome/Other graphical selection window, and then selected "Xen Virtualization", "C/C++ Compiler and Tools", and "Kernel Development". If there were any dependencies, I allowed them to be met. When I try "xm create -c /etc/xen/domain1", it starts the domain, but doesn't give me a console. Instead, it errors with: "xenconsole: xs_get_domain_path(): No such file or directory," with no more information. After installing xterm, an xterm pops up momentarily during xen setup, but then disappears. The created domain is likewise unbootable, but for a different reason: "Error: No kernel specified" I'll attach the new y2logs
Created attachment 49905 [details] y2logs after installing xterm
I have the same problem with SUSE Linux 10.0 final. Is there any progress on this bug?
Regarding comment #5: Although it may have appeared to start the domain, it really didn't (as per the xend*.log files). The loop device was busy; that was probably the problem. The "no such file or directory" error message is misleading; it comes from xs_talkv() down in xenstore. So: what happened is that the domain died, yet something then tried to talk to it via xenstore and of course couldn't find it, hence the later message. I think this is all fixed now. Loopback devices are getting properly cleaned up. Complain if this is still reproducible on a recent SLES 10 beta, otherwise I consider this fixed.......