Todd Deshane | 1 Dec 01:03
Picon
Gravatar

Re: Installing PV image from CDROM

On Sun, Nov 30, 2008 at 6:35 PM, J Newbie <j_nwb <at> yahoo.com> wrote:
> Thanks Todd.
>
> Could you please elaborate a bit more about what is wrong with CDROM ?
>

In vanilla Xen, as far as I know you can't use a CDROM directly yet.

The closest that I have seen is:
http://xen.markmail.org/search/?q=pv%20grub%20questions#query:pv%20grub%20questions+page:1+mid:cfyspt5vf3nj3thf+state:results

Open Solaris can install a PV guest from a CD or ISO I believe.

> Also,
> * I am ready to recreate/update initrd if required.
> * Any specific changes in Xen ? What version of Xen would this work on ? What type of change was made ?

I believe it is intended to work in the future, especially with
distros like Fedora that, as of the latest Fedora 10, or possibly a
bit earlier, are using Xen guest (domU) enabled kernels as the default
distro kernel.

> * What xen drivers are available for use with PV VMs ?
>
A decent sense of the PV options available can be found at:
http://wiki.xensource.com/xenwiki/XenParavirtOps

>
> I searched the archive for cdrom parvirtualized, pv etc.. but no good hit.
>
(Continue reading)

Cooper Quintin | 1 Dec 08:32

gentoo domU halting

Hello,
When I am booting my gentoo domU I get the following output to the
console and then it just hangs:
(full boot output can be found at http://pastecode.com/19771)
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI Shortcut mode
EXT2-fs warning (device sda1): ext2_fill_super: mounting ext3 filesystem
as ext2
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 108k freed

The dom0 is CentOS 5.2 and xen is version 3.1   I have tried all manner
of things and have no idea how to get this working.  Here is my xen
config file.

> kernel = "/boot/vmlinux-2.6.18-gentoo"
> memory = 700
> name = "bitsamurai"
> vif = [ '' ]
> dhcp = "dhcp"
> disk = ['file:/vm/gentoo.2008-0.img,sda1,w']
> root = "/dev/sda1 ro"
> extra = "gentoo=nodevfs"
Thanks

--

-- 
Cooper Quintin
Lead Developer - BitSamurai.net
http://BitSamurai.net
(Continue reading)

Thomas GOBET | 1 Dec 11:20
Picon

Nvidia doesn't work on xen kernel

Hi all.

I've just installed xen under lenny, and see that nvidia isn't supported on xen.

I installed xen module and header corresponding to my kernel version.

I changed my xorg.conf in order to load nv instead of nvidia module.

But now, I don't have any drivers which permit me to have compiz or anything else...

I tried to compile nvidia sources (nvidia-kernel-source) with module-assistant but nothing.

I done it with this command : m-a a-i nvidia-kernel-source.

An error occured during this installation :

    NVIDIA: left KBUILD.
    nvidia.ko failed to build!
    make[2]: *** [module] Error 1
    make[2]: left directory « /usr/src/modules/nvidia-kernel »
    make[1]: *** [build-stamp] Error 2
    make[1]: left directory « /usr/src/modules/nvidia-kernel »
    make: *** [kdist_image] Error 2
    BUILD FAILED!

See /var/cache/modass/nvidia-kernel-source.buildlog.2.6.26-1-xen-686.1228066050 for details

I attached buildlog file.

Hoping that somebody have an issue for my problem.

Thanks
/usr/bin/make  -f debian/rules clean
make[1]: entrant dans le répertoire « /usr/src/modules/nvidia-kernel »
# select which makefile to use.
rm -f /usr/src/modules/nvidia-kernel/Makefile || true
if [ 6 = 6  ]; then \
	     ln -s Makefile.kbuild Makefile ; \
	fi
if [  6 = 4  ]; then \
	     ln -s Makefile.nvidia Makefile ; \
	fi
if [ -e patch-stamp ]; then \
	   dpatch deapply-all ; \
	   rm -rf patch-stamp debian/patched ; \
	fi
if [ -f /usr/src/modules/nvidia-kernel/debian/control.template ]; then \
		cp  /usr/src/modules/nvidia-kernel/debian/control.template
/usr/src/modules/nvidia-kernel/debian/control; \
	fi
dh_testroot
rm -f build-stamp configure-stamp
/usr/bin/make clean SYSSRC=/lib/modules/2.6.26-1-xen-686/build -C
/usr/src/modules/nvidia-kernel/ -f Makefile 
make[2]: entrant dans le répertoire « /usr/src/modules/nvidia-kernel »
make[2]: quittant le répertoire « /usr/src/modules/nvidia-kernel »
rm -f /usr/src/modules/nvidia-kernel//Makefile || true; 	
rm /usr/src/modules/nvidia-kernel//gcc-check
rm /usr/src/modules/nvidia-kernel//cc-sanity-check
dh_clean
rm /usr/src/modules/nvidia-kernel/debian/control
rm /usr/src/modules/nvidia-kernel/debian/dirs
rm /usr/src/modules/nvidia-kernel/debian/override
make[1]: quittant le répertoire « /usr/src/modules/nvidia-kernel »
echo "ROOT_CMD = "
ROOT_CMD = 
/usr/bin/make  -f debian/rules binary_modules
make[1]: entrant dans le répertoire « /usr/src/modules/nvidia-kernel »
# select which makefile to use.
rm -f /usr/src/modules/nvidia-kernel/Makefile || true
if [ 6 = 6  ]; then \
	     ln -s Makefile.kbuild Makefile ; \
	fi
if [  6 = 4  ]; then \
	     ln -s Makefile.nvidia Makefile ; \
	fi
if ! gcc-4.1 -v 2> /dev/null  ; then \
	   echo "Compiler gcc-4.1 does not exist on the system" ; \
	   exit 1; \
	fi   
if [ -f /usr/src/modules/nvidia-kernel/debian/control.template ]; then \
		cp  /usr/src/modules/nvidia-kernel/debian/control.template
/usr/src/modules/nvidia-kernel/debian/control; \
	fi
if [ "i686" = "x86_64" ]; then \
		cp /usr/src/modules/nvidia-kernel/nv-kernel.o.x86_64
/usr/src/modules/nvidia-kernel/nv-kernel.o ; \
	fi
touch configure-stamp
dh_testdir
dh_testroot
PATCHLEVEL = 6 
Kernel compiler version : 4.1.2
Detected compiler version : 4.1.2
Using compiler gcc-4.1 version 4.1.2
touch /usr/src/modules/nvidia-kernel//gcc-check
touch /usr/src/modules/nvidia-kernel//cc-sanity-check
## Main Make ##
IGNORE_CC_MISMATCH=1 CC="gcc-4.1" /usr/bin/make -C /usr/src/modules/nvidia-kernel/ -f Makefile
SYSSRC=/lib/modules/2.6.26-1-xen-686/build   KBUILD_PARAMS="-C
/lib/modules/2.6.26-1-xen-686/build SUBDIRS=/usr/src/modules/nvidia-kernel" module;
make[2]: entrant dans le répertoire « /usr/src/modules/nvidia-kernel »
NVIDIA: calling KBUILD...
make CC=gcc-4.1 -C /lib/modules/2.6.26-1-xen-686/build SUBDIRS=/usr/src/modules/nvidia-kernel modules
make[3]: entrant dans le répertoire « /usr/src/linux-headers-2.6.26-1-xen-686 »
  CC [M]  /usr/src/modules/nvidia-kernel/nv.o
In file included from include/linux/list.h:6,
                 from include/linux/preempt.h:11,
                 from include/linux/spinlock.h:49,
                 from include/linux/seqlock.h:29,
                 from include/linux/time.h:8,
                 from include/linux/timex.h:57,
                 from include/linux/sched.h:54,
                 from include/linux/utsname.h:35,
                 from /usr/src/modules/nvidia-kernel/nv-linux.h:19,
                 from /usr/src/modules/nvidia-kernel/nv.c:14:
include/linux/prefetch.h: In function ‘prefetch_range’:
include/linux/prefetch.h:57: warning: pointer of type ‘void *’ used in arithmetic
In file included from /usr/src/modules/nvidia-kernel/nv-linux.h:34,
                 from /usr/src/modules/nvidia-kernel/nv.c:14:
/usr/src/modules/nvidia-kernel/conftest.h:1:2: error: #error remap_page_range() conftest failed!
/usr/src/modules/nvidia-kernel/conftest.h:3:2: error: #error vmap() conftest failed!
/usr/src/modules/nvidia-kernel/conftest.h:25:2: error: #error kmem_cache_create() conftest failed!
In file included from include/asm/mach-xen/asm/../../dma-mapping.h:9,
                 from include/asm/mach-xen/asm/dma-mapping.h:3,
                 from include/linux/dma-mapping.h:52,
                 from include/asm-generic/pci-dma-compat.h:7,
                 from include/asm/mach-xen/asm/pci.h:98,
                 from include/linux/pci.h:962,
                 from /usr/src/modules/nvidia-kernel/nv-linux.h:86,
                 from /usr/src/modules/nvidia-kernel/nv.c:14:
include/linux/scatterlist.h: In function ‘sg_virt’:
include/linux/scatterlist.h:199: warning: pointer of type ‘void *’ used in arithmetic
In file included from /usr/src/modules/nvidia-kernel/nv-linux.h:109,
                 from /usr/src/modules/nvidia-kernel/nv.c:14:
include/linux/highmem.h: In function ‘zero_user_segments’:
include/linux/highmem.h:134: warning: pointer of type ‘void *’ used in arithmetic
include/linux/highmem.h:134: warning: pointer of type ‘void *’ used in arithmetic
include/linux/highmem.h:134: warning: pointer of type ‘void *’ used in arithmetic
include/linux/highmem.h:134: warning: pointer of type ‘void *’ used in arithmetic
include/linux/highmem.h:137: warning: pointer of type ‘void *’ used in arithmetic
include/linux/highmem.h:137: warning: pointer of type ‘void *’ used in arithmetic
include/linux/highmem.h:137: warning: pointer of type ‘void *’ used in arithmetic
include/linux/highmem.h:137: warning: pointer of type ‘void *’ used in arithmetic
In file included from /usr/src/modules/nvidia-kernel/nv.c:14:
/usr/src/modules/nvidia-kernel/nv-linux.h:574:2: error: #error "NV_KMEM_CACHE_CREATE()
undefined (kmem_cache_create() unavailable)!"
/usr/src/modules/nvidia-kernel/nv.c: In function ‘nvidia_init_module’:
/usr/src/modules/nvidia-kernel/nv.c:1339: error: implicit declaration of function ‘NV_KMEM_CACHE_CREATE’
/usr/src/modules/nvidia-kernel/nv.c:1339: error: expected expression before ‘nv_stack_t’
/usr/src/modules/nvidia-kernel/nv.c:1349: error: implicit declaration of function ‘NV_KMEM_CACHE_DESTROY’
/usr/src/modules/nvidia-kernel/nv.c:1448: error: expected expression before ‘nv_pte_t’
/usr/src/modules/nvidia-kernel/nv.c: In function ‘nv_kern_open’:
/usr/src/modules/nvidia-kernel/nv.c:2027: warning: passing argument 2 of ‘request_irq’
from incompatible pointer type
make[4]: *** [/usr/src/modules/nvidia-kernel/nv.o] Erreur 1
make[3]: *** [_module_/usr/src/modules/nvidia-kernel] Erreur 2
make[3]: quittant le répertoire « /usr/src/linux-headers-2.6.26-1-xen-686 »
NVIDIA: left KBUILD.
nvidia.ko failed to build!
make[2]: *** [module] Erreur 1
make[2]: quittant le répertoire « /usr/src/modules/nvidia-kernel »
make[1]: *** [build-stamp] Erreur 2
make[1]: quittant le répertoire « /usr/src/modules/nvidia-kernel »
make: *** [kdist_image] Erreur 2
_______________________________________________
Xen-users mailing list
Xen-users <at> lists.xensource.com
http://lists.xensource.com/xen-users
Nicolas Courtel | 1 Dec 11:44
Picon

Re: Nvidia doesn't work on xen kernel

Thomas GOBET a écrit :
Hi all.

I've just installed xen under lenny, and see that nvidia isn't supported on xen.

I installed xen module and header corresponding to my kernel version.

I changed my xorg.conf in order to load nv instead of nvidia module.

But now, I don't have any drivers which permit me to have compiz or anything else...

I tried to compile nvidia sources (nvidia-kernel-source) with module-assistant but nothing.

I done it with this command : m-a a-i nvidia-kernel-source.

An error occured during this installation :

    NVIDIA: left KBUILD.
    nvidia.ko failed to build!
    make[2]: *** [module] Error 1
    make[2]: left directory « /usr/src/modules/nvidia-kernel »
    make[1]: *** [build-stamp] Error 2
    make[1]: left directory « /usr/src/modules/nvidia-kernel »
    make: *** [kdist_image] Error 2
    BUILD FAILED!

See /var/cache/modass/nvidia-kernel-source.buildlog.2.6.26-1-xen-686.1228066050 for details

I attached buildlog file.

Hoping that somebody have an issue for my problem.

This a known problem, the test that is made in the nVidia installation script is obsolete, you need to patch it.
You can find the patch here: http://www.nvnews.net/vbulletin/showthread.php?t=77597

--
Nicolas

_______________________________________________
Xen-users mailing list
Xen-users <at> lists.xensource.com
http://lists.xensource.com/xen-users
Dirk H. Schulz | 1 Dec 12:02
Picon

Re: Stability of XEN under high load Re: Stability of XEN under high load Re: Stability of XEN under high load

We do not have a problem of losing the bridges - they are still there, and 
brctl shows the interfaces of the disconnected domUs still on the bridge. 
There is just no connection to the outside world any more.

E.G.: sending pings between 2 domU (one of which is in the problematic 
disconnected state) and running tcpdump on both domUs shows:
- a ping from the disconnected domU to the other does not reach the 
interface of the dead domU internally: tcpdump does not register anything!
- a ping from the other domU to the disconnected one does not reach the 
interface of the disconnected domU.

So this could be a problem with the domU kernel. But since this is a hvm 
domU it is a standard kernel - I guess it must the network backend drivers, 
then.

The dom0 and domUs are ia64 (Itanium)-Systems, which could mean that we hit 
an ia64 specific bug.

Any idea? Every hint and help is greatly appreciated.

Dirk (working with Bernd, see below)

> I saw a problem of losing network bridges before that was related to
> problems with spanning tree. You may be experiencing a similar problem
>
> Rob Aronson
> Practice Manager, Novacoast
> USA
>
>
> On Sun, Nov 30, 2008 at 12:13 AM, Bernd Gotschy <Bernd.Gotschy@...> wrote:
>
>     Hallo,
>
>     we have a XEN server with Redhat 5.2 and XEN 3.0.3. We have two
>     problems.
>     We build an Oracle RAC with two XEN guest Redhat 4.4. When we add more
>     then 3 GB of RAM we cannot work with shared disks between the guests.
>     Looks like a XEN bug. We have to reduce the RAM to max. 3 GB.
>     Major problem is  that under high load we loose some of the network
>     interfaces and cannot get them working unless we reboot the guest.
>     We need RH 4.4 as guest operating system. The guests are HVM.
>     We have two bridges defined for the networker communication. It
>     seem one bridge is no longer functional. We have a XEN IA64 server.
>
>     Any idea how to solve this problem?
>
>     regards
>     Bernd
>
>     _______________________________________________
>     Xen-users mailing list
>     Xen-users@...
>     http://lists.xensource.com/xen-users
>
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@...
> http://lists.xensource.com/xen-users
akhilesh kumar | 1 Dec 12:24
Picon

Error: Device 0 (vif) could not be connected.Hotplug scripts not working.

Hi All

 

I am using xen 3.3.0 version and

I want to start network virtual interface on Dom U 

by using the following command  

 

# xend start
  ***************************************************************
  ***************************************************************
  ** WARNING: Currently emulating unsupported memory accesses  **
  **          in /lib/tls glibc libraries. The emulation is    **
  **          slow. To ensure full performance you should      **
  **          install a 'xen-friendly' (nosegneg) version of   **
  **          the library, or disable tls support by executing **
  **          the following as root:                           **
  **          mv /lib/tls /lib/tls.disabled                    **
  ** Offending process: xend (pid=1045)                        **
  ***************************************************************
  ***************************************************************
Continuing...
/usr/lib/python/xen/util/xsconstants.py:110: FutureWarning: hex/oct constants > sys.maxint will return positive values in Python 2.4 and up
  INVALID_SSIDREF = 0xFFFFFFFF
etc/xen/scripts/xen-network-common.sh
sh: =~: unknown operand
sh: =~: unknown operand
ifdown: interface eth0 not configured
ip: SIOCSIFNAME: Device or resource busy
suspend: event channel 9
BLKTAPCTRL[1091]: blktapctrl.c:736: blktapctrl: v1.0.0
BLKTAPCTRL[1091]: blktapctrl.c:738: Found driver: [raw image (aio)]
BLKTAPCTRL[1091]: blktapctrl.c:738: Found driver: [raw image (sync)]
BLKTAPCTRL[1091]: blktapctrl.c:738: Found driver: [vmware image (vmdk)]
BLKTAPCTRL[1091]: blktapctrl.c:738: Found driver: [ramdisk image (ram)]
BLKTAPCTRL[1091]: blktapctrl.c:738: Found driver: [qcow disk (qcow)]
BLKTAPCTRL[1091]: blktapctrl.c:738: Found driver: [qcow2 disk (qcow2)]
BLKTAPCTRL[1091]: blktapctrl.c:738: Found driver: [ioemu disk]
BLKTAPCTRL[1091]: blktapctrl_linux.c:21: Created /dev/xen/blktap0 device
#
# uname -r
2.6.18.8-xen
# xm create -c /mnt/xenU
Using config file "./xenU".
# Error: Device 0 (vif) could not be connected.Hotplug scripts not working.
 
In log message i found the following message
 
# tail -35 /var/log/xen/xen-hotplug.log
/etc/xen/scripts/vif-bridge: /etc/xen/scripts/vif-common.sh: line 66: syntax error: Bad fd number
/etc/xen/scripts/vif-bridge: line 94: syntax error: Bad fd number
 
 i have checked the  /etc/xen/scripts/vif-common.sh file i think there is no syntax error
57vifname=$(xenstore_read_default "$XENBUS_PATH/vifname" "")
58if [ "$vifname" ]
59then
60  if [ "$command" == "online" ] && ! ip link show "$vifname" >&/dev/null
61 then
62    do_or_die ip link set "$vif" name "$vifname"
63fi
64vif="$vifname"
65 fi
66
 
can any on help where i am going wrong , how to debugg or how to start network on Dom U
 
I am using the following confugration script
 
kernel = "/boot/vmlinuz-2.6.18.8-xenU"
ramdisk = "/boot/root_cramU.img"
memory = 80
name = "DomainU"
vif = ['ip=107.108.161.120, vifname=veth0']
root = "/dev/ram0 ro"
extra = "3 console=xvc "
 
Thanks,
Akhilesh
_______________________________________________
Xen-users mailing list
Xen-users <at> lists.xensource.com
http://lists.xensource.com/xen-users
Thomas Goirand | 1 Dec 12:41
Picon

Re: Stability of XEN under high load

> On Sun, Nov 30, 2008 at 12:13 AM, Bernd Gotschy
> <Bernd.Gotschy <at> inforsacom.com <mailto:Bernd.Gotschy <at> inforsacom.com>> wrote:
>     Major problem is  that under high load we loose some of the network
>     interfaces and cannot get them working unless we reboot the guest.

We have find out quite the opposite way. If one of the VM has no
activity, the ARP vs IP cache of most switch will discard the MAC of the
VMs. So we have made a very simple python script that we deploy on all
of our Xen servers, that simply does a ping of all VMs it finds in the
/etc/xen/auto folder. This way, the ARP cache gets refreshed, and
everything is working fine. Maybe this is what you are experiencing, no?
Anyway, bellow is the script, I hope that helps (take care, the procs =
line might appear on 2 lines as I didn't do an attachment).

Thomas

#!/usr/bin/env python

import glob
import re
import subprocess
import os
import sys

pathspec = "/etc/xen/auto/*"
regexp = re.compile(r"vif.*?=.*?ip=([0-9\. ]+)'")

files = glob.glob(pathspec)

contents = ( file(t).read(-1) for t in files )

def ips(contents):
        matches = regexp.findall("\n".join(list(contents)))
        for match in matches:
                mips = match.split(" ")
                for ip in mips: yield ip

devnull = file("/dev/null","w")
procs = (
subprocess.Popen(["ping",ip,"-c","1"],stdin=devnull,stdout=devnull,stderr=devnull)
for ip in ips(contents) )

returncodes = ( proc.wait() for proc in list(procs) )

sys.exit(sum(returncodes))
Venefax | 1 Dec 13:01
Picon

RE: Stability of XEN under high load

How often do you run this script?
Federico

-----Original Message-----
From: xen-users-bounces <at> lists.xensource.com
[mailto:xen-users-bounces <at> lists.xensource.com] On Behalf Of Thomas Goirand
Sent: Monday, December 01, 2008 6:41 AM
Cc: xen-users <at> lists.xensource.com
Subject: Re: [Xen-users] Stability of XEN under high load

> On Sun, Nov 30, 2008 at 12:13 AM, Bernd Gotschy
> <Bernd.Gotschy <at> inforsacom.com <mailto:Bernd.Gotschy <at> inforsacom.com>>
wrote:
>     Major problem is  that under high load we loose some of the network
>     interfaces and cannot get them working unless we reboot the guest.

We have find out quite the opposite way. If one of the VM has no
activity, the ARP vs IP cache of most switch will discard the MAC of the
VMs. So we have made a very simple python script that we deploy on all
of our Xen servers, that simply does a ping of all VMs it finds in the
/etc/xen/auto folder. This way, the ARP cache gets refreshed, and
everything is working fine. Maybe this is what you are experiencing, no?
Anyway, bellow is the script, I hope that helps (take care, the procs =
line might appear on 2 lines as I didn't do an attachment).

Thomas

#!/usr/bin/env python

import glob
import re
import subprocess
import os
import sys

pathspec = "/etc/xen/auto/*"
regexp = re.compile(r"vif.*?=.*?ip=([0-9\. ]+)'")

files = glob.glob(pathspec)

contents = ( file(t).read(-1) for t in files )

def ips(contents):
        matches = regexp.findall("\n".join(list(contents)))
        for match in matches:
                mips = match.split(" ")
                for ip in mips: yield ip

devnull = file("/dev/null","w")
procs = (
subprocess.Popen(["ping",ip,"-c","1"],stdin=devnull,stdout=devnull,stderr=de
vnull)
for ip in ips(contents) )

returncodes = ( proc.wait() for proc in list(procs) )

sys.exit(sum(returncodes))

_______________________________________________
Xen-users mailing list
Xen-users <at> lists.xensource.com
http://lists.xensource.com/xen-users
Venefax | 1 Dec 13:07
Picon

RE: Stability of XEN under high load

I get all these errors when I run the script. I named it "refresh.py". It is
located in /root. Am I wrong?

linux-tlxs:~ # ./refresh.py
Traceback (most recent call last):
  File "./refresh.py", line 25, in ?
    returncodes = ( proc.wait() for proc in list(procs) )
  File "./refresh.py", line 23, in <generator expression>
    procs =
(subprocess.Popen(["ping",ip,"-c","1"],stdin=devnull,stdout=devnull,stderr=d
evnull)
  File "./refresh.py", line 17, in ips
    matches = regexp.findall("\n".join(list(contents)))
  File "./refresh.py", line 14, in <generator expression>
    contents = ( file(t).read(-1) for t in files )
IOError: [Errno 21] Is a directory

-----Original Message-----
From: xen-users-bounces <at> lists.xensource.com
[mailto:xen-users-bounces <at> lists.xensource.com] On Behalf Of Thomas Goirand
Sent: Monday, December 01, 2008 6:41 AM
Cc: xen-users <at> lists.xensource.com
Subject: Re: [Xen-users] Stability of XEN under high load

> On Sun, Nov 30, 2008 at 12:13 AM, Bernd Gotschy
> <Bernd.Gotschy <at> inforsacom.com <mailto:Bernd.Gotschy <at> inforsacom.com>>
wrote:
>     Major problem is  that under high load we loose some of the network
>     interfaces and cannot get them working unless we reboot the guest.

We have find out quite the opposite way. If one of the VM has no
activity, the ARP vs IP cache of most switch will discard the MAC of the
VMs. So we have made a very simple python script that we deploy on all
of our Xen servers, that simply does a ping of all VMs it finds in the
/etc/xen/auto folder. This way, the ARP cache gets refreshed, and
everything is working fine. Maybe this is what you are experiencing, no?
Anyway, bellow is the script, I hope that helps (take care, the procs =
line might appear on 2 lines as I didn't do an attachment).

Thomas

#!/usr/bin/env python

import glob
import re
import subprocess
import os
import sys

pathspec = "/etc/xen/auto/*"
regexp = re.compile(r"vif.*?=.*?ip=([0-9\. ]+)'")

files = glob.glob(pathspec)

contents = ( file(t).read(-1) for t in files )

def ips(contents):
        matches = regexp.findall("\n".join(list(contents)))
        for match in matches:
                mips = match.split(" ")
                for ip in mips: yield ip

devnull = file("/dev/null","w")
procs = (
subprocess.Popen(["ping",ip,"-c","1"],stdin=devnull,stdout=devnull,stderr=de
vnull)
for ip in ips(contents) )

returncodes = ( proc.wait() for proc in list(procs) )

sys.exit(sum(returncodes))

_______________________________________________
Xen-users mailing list
Xen-users <at> lists.xensource.com
http://lists.xensource.com/xen-users
Dirk H. Schulz | 1 Dec 13:16
Picon

Re: Stability of XEN under high load

Thomas,

thanks for your input, but we are sure we do not have an arp problem.

The phenomenon is that suddenly under heavy load a vif stops working - no 
connection to others on the bridge is possible any more then, it does not 
send out anything (not even arp requests are sent, then). Since this is 
happening under heavy load the mac of this vif is well listed in all 
concerned arp caches of others on the bridge.

In the mean time we found out that we can trigger this phenomenon with 
certain tests that create massive network I/O. Is there any known bugs with 
xen 3.0.3 on ia64 concerning network load?

Dirk

--On 1. Dezember 2008 19:41:02 +0800 Thomas Goirand <thomas <at> goirand.fr> 
wrote:

>> On Sun, Nov 30, 2008 at 12:13 AM, Bernd Gotschy
>> <Bernd.Gotschy <at> inforsacom.com <mailto:Bernd.Gotschy <at> inforsacom.com>>
>> wrote: Major problem is  that under high load we loose some of the
>>     network interfaces and cannot get them working unless we reboot the
>>     guest.
>
> We have find out quite the opposite way. If one of the VM has no
> activity, the ARP vs IP cache of most switch will discard the MAC of the
> VMs. So we have made a very simple python script that we deploy on all
> of our Xen servers, that simply does a ping of all VMs it finds in the
> /etc/xen/auto folder. This way, the ARP cache gets refreshed, and
> everything is working fine. Maybe this is what you are experiencing, no?
> Anyway, bellow is the script, I hope that helps (take care, the procs =
> line might appear on 2 lines as I didn't do an attachment).
>
> Thomas
>
># !/usr/bin/env python
>
> import glob
> import re
> import subprocess
> import os
> import sys
>
> pathspec = "/etc/xen/auto/*"
> regexp = re.compile(r"vif.*?=.*?ip=([0-9\. ]+)'")
>
> files = glob.glob(pathspec)
>
> contents = ( file(t).read(-1) for t in files )
>
> def ips(contents):
>         matches = regexp.findall("\n".join(list(contents)))
>         for match in matches:
>                 mips = match.split(" ")
>                 for ip in mips: yield ip
>
> devnull = file("/dev/null","w")
> procs = (
> subprocess.Popen(["ping",ip,"-c","1"],stdin=devnull,stdout=devnull,stderr
> =devnull) for ip in ips(contents) )
>
> returncodes = ( proc.wait() for proc in list(procs) )
>
> sys.exit(sum(returncodes))
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users <at> lists.xensource.com
> http://lists.xensource.com/xen-users

--------------------------------------------------------------
Dirk H. Schulz
IT Systems Service
Wiesenweg 12, 85567 Grafing
Tel. 0 80 92/86 25 68
Fax. 0 80 92/86 25 72
--------------------------------------------------------------
Technik vom Feinsten - und das nötige Tuning

Gmane