[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] migrate ERROR


  • To: xen-users@xxxxxxxxxxxxxxxxxxx
  • From: "Javier Terceiro" <correolista@xxxxxxxxx>
  • Date: Fri, 27 Oct 2006 15:48:36 +0200
  • Delivery-date: Fri, 27 Oct 2006 06:49:10 -0700
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=TUMdS51ChqXvLBrHxRh9NP1JUXvF7FYRDlxbigcm7v41wS/vhBtoYWRZiMquy2mik7izkj86yQ3o2s0AjHx1x5eH2dZEvNKG1+dtCT9AIzppTJwf5sd2CY/G7W+gwYQSr5+KjxK5misjhJ4IoqDD2gcmthOK/Br0T2eBzW7rFcw=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

Hi,

my xend-config.sxp config id:

(xend-http-server yes)
(xend-relocation-server yes)
(xend-port            8000)
(xend-relocation-port 8002)
(xend-relocation-address '')
### (xend-relocation-hosts-allow '')

and live migration is OK. You can probed modify your config.

luck.


2006/10/27, tgh <tianguanhua@xxxxxxxxxx>:
Hi
I setup xen-3.0.2 on two nodes , and modify the xend-config.sxp

but when I try to migrate a vm from one node to a other , error arises:
Error: (104, 'Connection reset by peer')

Is there something wrong with the xend-config.sxp or something else
needed to be instored or modified to make the migrate work well
could anyone give a help

Thanks in advance

xend-config.sxp:


#
# Xend configuration file.
#

# This example configuration is appropriate for an installation that
# utilizes a bridged network configuration. Access to xend via http
# is disabled.

# Commented out entries show the default for that entry, unless otherwise
# specified.

#(logfile /var/log/xend.log)
#(loglevel DEBUG)

#(xend-http-server no)
#(xend-unix-server no)
#(xend-tcp-xmlrpc-server no)
#(xend-unix-xmlrpc-server yes)
#(xend-relocation-server no)
(xend-relocation-server yes)

#(xend-unix-path /var/lib/xend/xend-socket)

# Port xend should use for the HTTP interface, if xend-http-server is set.
#(xend-port 8000)

# Port xend should use for the relocation interface, if
xend-relocation-server
# is set.
(xend-relocation-port 8002)

# Address xend should listen on for HTTP connections, if xend-http-server is
# set.
# Specifying 'localhost' prevents remote connections.
# Specifying the empty string '' (the default) allows all connections.

1,1 ???
#(xend-address '')
#(xend-address localhost)

# Address xend should listen on for relocation-socket connections, if
# xend-relocation-server is set.
# Meaning and default as for xend-address above.
(xend-relocation-address '')

# The hosts allowed to talk to the relocation port. If this is empty (the
# default), then all connections are allowed (assuming that the connection
# arrives on a port and interface on which we are listening; see
# xend-relocation-port and xend-relocation-address above). Otherwise, this
# should be a space-separated sequence of regular expressions. Any host with
# a fully-qualified domain name or an IP address that matches one of these
# regular expressions will be accepted.
#
# For example:
# (xend-relocation-hosts-allow '^localhost$ ^.*\.example\.org$')
#
(xend-relocation-hosts-allow '')
#(xend-relocation-hosts-allow '^localhost$')

# The limit (in kilobytes) on the size of the console buffer
#(console-limit 1024)

##
# To bridge network traffic, like this:
#
# dom0: fake eth0 -> vif0.0 -+
# |
# bridge -> real eth0 -> the network
# |
# domU: fake eth0 -> vifN.0 -+
#
# use
#
# (network-script network-bridge)
#
# Your default ethernet device is used as the outgoing interface, by
default.
# To use a different one (e.g. eth1) use
#
# (network-script 'network-bridge netdev=eth1')
#
# The bridge is named xenbr0, by default. To rename the bridge, use
#
# (network-script 'network-bridge bridge=<name>')
#(network-script 'network-bridge netdev=eth1 bridge=xenbr0')
(network-script my-network-bridge)
#
# It is possible to use the network-bridge script in more complicated
# scenarios, such as having two outgoing interfaces, with two bridges, and
# two fake interfaces per guest domain. To do things like this, write
# yourself a wrapper script, and call network-bridge from it, as
appropriate.
#
(network-script network-bridge)

# The script used to control virtual interfaces. This can be overridden on a
# per-vif basis when creating a domain or a configuring a new vif. The
# vif-bridge script is designed for use with the network-bridge script, or
# similar configurations.
#
# If you have overridden the bridge name using
# (network-script 'network-bridge bridge=<name>') then you may wish to
do the
# same here. The bridge name can also be set when creating a domain or
# configuring a new vif, but a value specified here would act as a default.
#
# If you are using only one bridge, the vif-bridge script will discover
that,
# so there is no need to specify it explicitly.
#
(vif-script vif-bridge)


## Use the following if network traffic is routed, as an alternative to the
# settings for bridged networking given above.
#(network-script network-route)
#(vif-script vif-route)


## Use the following if network traffic is routed with NAT, as an
alternative
# to the settings for bridged networking given above.
#(network-script network-nat)
#(vif-script vif-nat)


# Dom0 will balloon out when needed to free memory for domU.
# dom0-min-mem is the lowest memory level (in MB) dom0 will get down to.
# If dom0-min-mem=0, dom0 will never balloon out.
(dom0-min-mem 196)

# In SMP system, dom0 will use dom0-cpus # of CPUS
# If dom0-cpus = 0, dom0 will take all cpus available
(dom0-cpus 0)

# Whether to enable core-dumps when domains crash.
#(enable-dump no)







_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users



--
          .~.
       ( 0 0 )
       /  V  \
      //       \\     Power by Debian
    /((   _    ))\
     oo0 0oo

A greeting,

Javier.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.