doesn't manage local machine

[Peter Cordes]

Binary package hint: xenman

I installed xenman on my AMD64 Edgy system, on a core 2 duo.

I'm running the kernel from xen-image-xen0-2.6.16-11.2-generic 2.6.16-11.2 as dom0 on
xen-hypervisor-3.0-amd64 3.0.3-0ubuntu1. I don't have any domUs, but xen-utils-3.0 is installed, and xend is running.

xenman claims the local machine will show up as a manageable node "if the prereqs are met", but it doesn't say what the pre-reqs are for the local machine, only for remote machines. The docs don't say exactly how it tries to interact with xen, so I can't tell if it doesn't like what it finds in some config file, or what.

[Peter Cordes (peter-cordes)]

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(0x7fffffea3950, 32) = 0
9220 ioctl(7, SNDCTL_DSP_RESET, 0x7fffffea38f0) = -1 ENOSYS (Function not imple
9220 ioctl(7, SNDCTL_DSP_RESET, 0x7fffffea38f0) = -1 ENOSYS (Function not imple
9220 close(7) = 0

 So maybe a newer kernel would help, but I haven't found anything but 2.6.16.* kernels, even in the xen unstable mercurial repository. I need the drivers in 2.6.19 (e1000 and PATA_MARVELL) to do more than play with xen. :/

[John Moser (nigelenki)]

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.

[Jd (jd-jedi)]

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.

[Peter Cordes (peter-cordes)]

On Mon, Apr 30, 2007 at 05:47:02PM -0000, 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 paravirtualized
domains.

 I'm not using Xen now, though, because I couldn't get it to give a PCI
video card to a hardware-virtualized domain. (I wanted to build a
multi-seat system, with Windows seeing a real PCI vid card.) I got the
impression there's no MMU code for doing that yet.

 I haven't tried Xen at all since upgrading to Feisty.

--
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cor , des.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BC

[Matt Mossholder (matt-mossholder)]

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

[Jd (jd-jedi)]

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 ?
   -- localhost is not shown. (I am assuming that this is the problem. please confirm.)
   -- Cant open a particular VM config file ?
   etc..

Can u please attach/cutpaste the dom config file

Can you please attach/paste /etc/hosts file.

Do you see any xenman stack traces ?

Can you please confirm strace behavior mentioned in the bug.

Thanks
/Jd

[Matt Mossholder (matt-mossholder)]

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:

           [127.0.0.1]
           is_remote = False

Thanks for the tip on xenman using XML-RPC for local communications. That is what led me down the path to a solution :)

           ---Matt

[Matt Mossholder (matt-mossholder)]

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 should look like:

#!/bin/bash
#
# Wrapper script to start xenman
#

if [ $1 == "--xendir" ]; then
         echo -n `ls -d /usr/lib/xen /usr/lib/xen-* | sort | head -n1`
         exit 0
fi
PYTHONPATH=$PYTHONPATH:`xenman --xendir` /lib/python python /usr/share/xenman/src/xenman.py

Regards,
     --Matt

[Jd (jd-jedi)]

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/xend/xmlrpc.sock

   2. Also, localhost should not be.. need not be added in the way yo have suggested. It can be used as a workaround though.
        XenMan does a couple of check to see if the local node should be added or not.
        1. look for 'xen' in the platform.release()
        2. you should be logged in as root.

   One way is to put few print statements in xenman.py to find out what exactly is causing the problem.

   python -c "import platform; print platform.release()"

  for the packaging on ubutu platform, I will send a note to the contributor. <email address hidden>

  Thanks for following this up.
/Jd

[Matt Mossholder (matt-mossholder)]

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 and without pae, respectively). Maybe a better way to check would be to look for the existence of /proc/xen?

     Regards,
             --Matt

[Matt Mossholder (matt-mossholder)]

...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

[Jd (jd-jedi)]

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

[Jeff Schroeder (sejeff)]

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 `ls -d /usr/lib/xen /usr/lib/xen-* | sort | head -n1`
         exit 0
fi
PYTHONPATH=$PYTHONPATH:`xenman --xendir`:/lib/python python /usr/share/xenman/src/xenman.py

[Matt Mossholder (matt-mossholder)]

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

[William Grant (wgrant)]

This seems fixed in Gutsy.