This seems fixed in Gutsy.
** Changed in: xenman (Ubuntu)
Status: Confirmed => Fix Released
--
doesn't manage local machine
https://bugs.launchpad.net/bugs/76500
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bu
Jeff,
Not my script, all I did was add /usr/lib/xen to the echo statement... The
space might be my fault. I don't remember if I typed it in by hand, or cut and
pasted.
Thanks for the fix, though...
--Matt
--
doesn't manage local machine
https://bugs.launchpad.net/bugs/76500
You recei
Matt, your script doesn't seem to work. Ontop of that, it doesn't check
if $1 is set. Ontop of that, you have a space in the PYTHONDIR so it
isn't even properly set. Maybe this is better:
#!/bin/bash
#
# Wrapper script to start xenman
#
if [ $# -eq 1 -a $1 == "--xendir" ]; then
echo -n
good catch. Now things have explanation.
This would need a small patch to better determine the xen env.
We can publish the workaround to add localhost with remote=False.
Will publish a patch on Convirt/XenMan site soon.
thanks for leading this to conclusion.
/Jd
--
doesn't manage local machine
...and now that I have sent that... I realize /proc/xen exists in the domUs as
well. Perhaps one of the other /proc entries?
--Matt
--
doesn't manage local machine
https://bugs.launchpad.net/bugs/76500
You received this bug notification because you are a member of Ubuntu
Bugs, which is the
I come with answers
1. I referenced the unix socket as not being enabled, not the tcp
socket. So we're on the same page, it seems.
2. Ubuntu does not use the string "xen" anywhere in the
platform.release. For example, on feisty-xen, it is 2.6.19-4-server or
2.6.19-4-generic (for with
Hi Matt,
This is good find.. that you can start managing stuff :), but we
need to do little bit of digging up.
Here are some observations :
1. on local machine tcp xmlrpc server should not be required to be enabled.
XenMan should use the local interface i.e. unix sockets
/var/run/x
One more on this one... the wrapper in /usr/sbin/xenman is incorrectly
setting the xendir variable. It is picking up /usr/lib/xen-ioemu-3.0 as
xendir, when it is actually /usr/lib/xen. This, in tern, means that the
consoles don't work, as xenconsole can't be located.
Here is what the wrapper shou
I've figured this out...
There are two issues:
1) Shipped xend-config.sxp from the xen-utils package does not enable
the xend-unix-xmlrpc-server
2) The shipped xenman.conf does not have an entry for localhost included
in it. Add the following entry enabled xenman to manage the local
system:
lets take step by step to narrow this one down.
XenMan uses xml-rpc over socket for management. For local node it uses
the UNIX socket while for remote it uses the TCP socket through ssh
tunneling.
What exactly is the behavior from a client perspective ?
-- xenman does not start ?
-- local
I can confirm this as well. I have several domU's created with xen-
toolsunder feisty which work fine, but for whatever reason, xenman can't
manage the local system. I'm more than willing to provide information to
get this resolved. Just let me know what you need.
--Matt
--
doesn't man
On Mon, Apr 30, 2007 at 05:47:02PM -, Jd wrote:
> Can u please confirm that you can use Xen with xm command line. There
> seems to be some problem with Xen itself. /proc/xen/privcmd seems to be
> xc_handle critical for xen operation.
Yes, Xen itself worked. I was able to create a couple para
Can u please confirm that you can use Xen with xm command line. There
seems to be some problem with Xen itself. /proc/xen/privcmd seems to be
xc_handle critical for xen operation.
--
doesn't manage local machine
https://bugs.launchpad.net/bugs/76500
You received this bug notification because you
Confirmed, this also happens with 2.6.17 and 2.6.19 Xen dom0 kernels.
Worked in Edgy, upgraded to Feisty and it ceased to work. Tried this
multiple times and each time I upgrade to Feisty XenMan ceases
functioning.
** Changed in: xenman (Ubuntu)
Status: Unconfirmed => Confirmed
--
doesn'
I found something in an strace, around line 6940 (57%):
9220 open("/proc/xen/privcmd", O_RDWR) = 7
9220 fcntl(7, F_GETFD) = 0
9220 fcntl(7, F_SETFD, FD_CLOEXEC) = 0
9220 mlock(0x7fea3950, 32) = 0
9220 ioctl(7, SNDCTL_DSP_RESET, 0x7fea38f0) = -1 ENOSYS (Func
15 matches
Mail list logo
