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

[Xen-users] Re: Xen-users Digest, Vol 42, Issue 65


  • To: xen-users@xxxxxxxxxxxxxxxxxxx
  • From: "John @ New Frontiers" <jbanas@xxxxxxxx>
  • Date: Mon, 11 Aug 2008 12:24:45 -0400
  • Delivery-date: Mon, 11 Aug 2008 09:25:28 -0700
  • List-id: Xen user discussion <xen-users.lists.xensource.com>


__________
John Banas
Senior Network Administrator

New Frontiers Telecommunications
49 Summit Avenue
Hagerstown, Maryland 21740
P: 301-791-3800

Submit a trouble ticket:
http://www.nfis.com/cgi-bin/troubleticket/ttx.cgi?cmd=newticket

New Frontiers Telecommunications offers local voice and high speed Internet connections for residential and business customers in Western Maryland and West Virginia.


On Aug 11, 2008, at 12:07 PM, xen-users-request@xxxxxxxxxxxxxxxxxxx wrote:

Send Xen-users mailing list submissions to
        xen-users@xxxxxxxxxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.xensource.com/mailman/listinfo/xen-users
or, via email, send a message with subject or body 'help' to
        xen-users-request@xxxxxxxxxxxxxxxxxxx

You can reach the person managing the list at
        xen-users-owner@xxxxxxxxxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Xen-users digest..."


Today's Topics:

  1. tap interface shuts down for unknown reasons (James Roman)
  2. Re: Re: DomU network configuration problem (Tej)
  3. Re: xen client side package. (jd)
  4. unsubscribe (Szabolcs Feczak)


----------------------------------------------------------------------

Message: 1
Date: Mon, 11 Aug 2008 11:31:42 -0400
From: James Roman <james_roman@xxxxxxxxxx>
Subject: [Xen-users] tap interface shuts down for unknown reasons
To: xen-users@xxxxxxxxxxxxxxxxxxx
Message-ID: <48A05B5E.8010904@xxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"

One of our guest servers has recently begun to disappear from the
network after working properly for various periods of time. It seems
that for some reason the tap interface for the guest domain disables
itself. I have recently changed our network setup, but I am not sure
that it is related.

Our current network configuration assigns a eth0 to Dom0. The guest
domains use two bonded NICs (eth2 and eth3) which are bonded together
(mode 4 across a Cisco channel group) into bond0. The guest domains
bridge to bond0. eth0 and bond0 connect to two different VLANs. I have
NOT configured trunking across any interface.

When the guests are started they are accessible by the network. After a period of time one of the guest domains (win2k3) disappears. I have two
guest domains running (1 win2k3 and 1 Centos Linux), and it seems to
only affect the windows guest. The event log on the guest server shows
nothing unusual (in fact it appears to be functioning normally based on
CPU and memory usage via xm list.)  The message log on Dom0 shows the
following:

   Aug 11 10:08:00 vs-001 kernel: xenbr0: port 3(tap1) entering
   disabled state
   Aug 11 10:08:00 vs-001 kernel: device tap1 left promiscuous mode
   Aug 11 10:08:00 vs-001 kernel: xenbr0: port 3(tap1) entering
   disabled state
   Aug 11 10:08:00 vs-001 avahi-daemon[4269]: Interface tap1.IPv6 no
   longer relevant for mDNS.
   Aug 11 10:08:00 vs-001 avahi-daemon[4269]: Leaving mDNS multicast
group on interface tap1.IPv6 with address fe80::60a5:51ff:feb5:bf10.
   Aug 11 10:08:00 vs-001 avahi-daemon[4269]: Withdrawing address
   record for fe80::60a5:51ff:feb5:bf10 on tap1.

ifconfig on Dom0 no longer lists tap1 (which is associated with the
windows guest). Not knowing how to manually rebuild the interface, the
only method I can find to restore contact to the guest domain is to
destroy it and bring it back up. Dom0 message log shows the following
and the guest domain is once again accessible via network and via VNC
console port.

   Aug 11 10:32:26 vs-001 kernel: xenbr0: port 6(vif5.0) entering
   disabled state
   Aug 11 10:32:26 vs-001 kernel: device vif5.0 left promiscuous mode
   Aug 11 10:32:26 vs-001 kernel: xenbr0: port 6(vif5.0) entering
   disabled state
   Aug 11 10:32:29 vs-001 kernel: device tap1 entered promiscuous mode
   Aug 11 10:32:29 vs-001 kernel: xenbr0: port 3(tap1) entering
   learning state
   Aug 11 10:32:29 vs-001 kernel: xenbr0: topology change detected,
   propagating
   Aug 11 10:32:29 vs-001 kernel: xenbr0: port 3(tap1) entering
   forwarding state
Aug 11 10:32:30 vs-001 kernel: device vif6.0 entered promiscuous mode
   Aug 11 10:32:30 vs-001 kernel: ADDRCONF(NETDEV_UP): vif6.0: link is
   not ready
   Aug 11 10:32:31 vs-001 avahi-daemon[4269]: New relevant interface
   tap1.IPv6 for mDNS.
   Aug 11 10:32:31 vs-001 avahi-daemon[4269]: Joining mDNS multicast
   group on interface tap1.IPv6 with address fe80::20e8:6ff:fe68:45ca.
   Aug 11 10:32:31 vs-001 avahi-daemon[4269]: Registering new address
   record for fe80::20e8:6ff:fe68:45ca on tap1.

First, is there any way to manually rebuild the tap interface when it
goes down, so that I don't have to destroy the guest domain?

Second, is there any way to determine why the tap interface for that
guest keeps going down? Is there a fundamental problem with the current
network configuartion that is causing this anomaly?

Vitals:
Dom0 Centos 5.2
xen-3.0.3-64.el5_2.1

--

James D. Roman
Sr. Network Administrator
Science Systems and Application, Inc.
Phone: 301-867-2101

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://lists.xensource.com/archives/html/xen-users/attachments/20080811/768de46c/attachment.html

------------------------------

Message: 2
Date: Mon, 11 Aug 2008 21:19:33 +0530
From: Tej <bewith.tej@xxxxxxxxx>
Subject: Re: [Xen-users] Re: DomU network configuration problem
To: shubham <shubham.sharma@xxxxxx>
Cc: xen-users@xxxxxxxxxxxxxxxxxxx
Message-ID:
        <f1c9d250808110849t74d2e964j5be0f2ec228a82e5@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1

On 8/11/08, shubham <shubham.sharma@xxxxxx> wrote:
Tej <bewith.tej <at> gmail.com> writes:


---------------8<------------------

You can do following steps:

1. Assign any private IP to your DomU
2. Assign the subnet gateway to the domU, above vuf configuration is
fine i guess.

3. Now as dom0 is on different subnet, create the eth0 (i assume here that eth0 domU and eth0 of dom0 is connected to xenbr0 ) alias as a
gateway for domU.
   In dom0:
   ifconfig eth0 add domU-gateway netmask.
4. Now that gateway should be pingable
5. Now add the forwarding rules
   echo 1 >/procsys/net/ipv4/ip_forward
  Now you should be able to ping the eth0 on dom0.
6. Add the masq rule as above.
iptables -t nat -A POSTROUTING -j MASQUERADE (use the eth0 address)
7. Now you should be able to ping google.com

HTH

-tej
-------------------8<--------------

i tried these instructions but i could not proceed till step 4.
i was not able to ping the gateway from domU.

only one reason i could see xenbridge is not connecting dom0 and domU

ensure this connectivity using brctl show:

xenbr0           8000.xxxxx     no                vif0.0
                                                              peth0

vif<domU-id>.0
if not eth0.0 will not be pingable.

try this if still problem  post following
1. domU ifconfig & route -n

ifconfig on domU gives the following output:
xentestl: # ifconfig
eth8      Link encap:Ethernet HWaddr 00:16:3E:5D:1F:3D
        inet addr: 192.168.1.12 Bcast:192.168.1.255 Mask:255.255.255.0
        inet6 addr: fe80: :216:3eff:fe5d:lf3d/64 Scope:Link
        UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
        RX packets:0 errors:0 dropped:0 ouerruns:0 frane:0
        TX packets:8 errors:0 dropped:0 ouerruns:0 carrier:0
        collisions:0 txqueuelen:1000
        RX bytes:0 (0.0 b) TX bytes:592 (592.0 b)
        Interrupt : 177 Base address :0x2000
lo      Link encap:Local Loopback
        inet addr: 127.0.0.1 Mask:255.0.O .0
        inet6 addr: ::1/128 Scope:Host
        UP LO0PBACX RUNNING MTU:16436 Metric:1
        RX packets:50 errors:0 dropped:0 ouerruns:0 frame:0
        TX packets:50 errors:0 dropped:0 ouerruns:0 carrier:0
        collisions:0 txqueuelen:0
        RX bytes:7943 (7.7 Kb) TX bytes:7943 (7.7 Kb)

route -n on domU shows the following result:
Destination Gateway Genmask Flags Metric Ref Use
Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth8 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth8 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo

2. dom0 ifconfig & route -n

dom0 ifconfig has the following result :

dummy0    Link encap:Ethernet  HWaddr 52:B0:12:64:EA:DD
inet addr:10.33.195.40 Bcast:10.33.195.255 Mask: 255.255.255.0
         inet6 addr: fe80::50b0:12ff:fe64:eadd/64 Scope:Link
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:0 errors:0 dropped:0 overruns:0 frame:0
         TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:0
         RX bytes:0 (0.0 b)  TX bytes:468 (468.0 b)

eth0      Link encap:Ethernet  HWaddr 00:19:DB:51:BB:4A
inet addr:10.33.196.47 Bcast:10.33.196.255 Mask: 255.255.255.0
         inet6 addr: fe80::219:dbff:fe51:bb4a/64 Scope:Link
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:101210 errors:0 dropped:0 overruns:0 frame:0
         TX packets:116297 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:1000
         RX bytes:7828179 (7.4 Mb)  TX bytes:160785457 (153.3 Mb)
         Base address:0x3000 Memory:b8340000-b8360000

eth0:0    Link encap:Ethernet  HWaddr 00:19:DB:51:BB:4A
inet addr:192.168.1.255 Bcast:10.33.196.255 Mask: 255.255.255.0
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         Base address:0x3000 Memory:b8340000-b8360000

lo        Link encap:Local Loopback
         inet addr:127.0.0.1  Mask:255.0.0.0
         inet6 addr: ::1/128 Scope:Host
         UP LOOPBACK RUNNING  MTU:16436  Metric:1
         RX packets:58768 errors:0 dropped:0 overruns:0 frame:0
         TX packets:58768 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:0
         RX bytes:305180714 (291.0 Mb)  TX bytes:305180714 (291.0 Mb)

tap0      Link encap:Ethernet  HWaddr 9E:A2:FE:02:92:1D
         inet6 addr: fe80::9ca2:feff:fe02:921d/64 Scope:Link
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:8 errors:0 dropped:0 overruns:0 frame:0
         TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:500
         RX bytes:592 (592.0 b)  TX bytes:468 (468.0 b)

vif10.0   Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF
         UP BROADCAST NOARP  MTU:1500  Metric:1
         RX packets:0 errors:0 dropped:0 overruns:0 frame:0
         TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:32
         RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

xenbr0    Link encap:Ethernet  HWaddr 9E:A2:FE:02:92:1D
         inet6 addr: fe80::f01a:3ff:fe74:43db/64 Scope:Link
         UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
         RX packets:38 errors:0 dropped:0 overruns:0 frame:0
         TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:0
         RX bytes:2304 (2.2 Kb)  TX bytes:0 (0.0 b)

route -n on dom0 is:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
10.33.195.0 0.0.0.0 255.255.255.0 U 0 0 0
dummy0
10.33.196.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 10.33.196.35 0.0.0.0 UG 0 0 0 eth0

3. brctl show
brctl on dom0 gives the following output:

xenbr0          8000.9ea2fe02921d       no              vif0.0
                                                       pdummy0
                                                       tap0
                                                       vif10.0

Since you have eth8 on domU there must be corresponding vif10.8
attached to xenbr0.

tomorrow i will look back to your network configuration, its totally screwed up.





-tej


is there any method to know that the eth0 of domU is connected to xenbr0

one more information that i missed out last time was that i am using
full
virtualization. so i just want to confirm that are the above steps fine
for full virtualization as well?




_______________________________________________
Xen-users mailing list
Xen-users <at> lists.xensource.com
http://lists.xensource.com/xen-users







_______________________________________________
Xen-users mailing list
Xen-users <at> lists.xensource.com
http://lists.xensource.com/xen-users







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




------------------------------

Message: 3
Date: Mon, 11 Aug 2008 09:06:42 -0700 (PDT)
From: jd <jdsw2002@xxxxxxxxx>
Subject: Re: [Xen-users] xen client side package.
To: deshantm@xxxxxxxxx
Cc: XenUsers <xen-users@xxxxxxxxxxxxxxxxxxx>
Message-ID: <61824.44774.qm@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii

Todd,
  Thanks for detailed feedback... see inline...


--- On Sun, 8/10/08, Todd Deshane <deshantm@xxxxxxxxx> wrote:

From: Todd Deshane <deshantm@xxxxxxxxx>
Subject: Re: [Xen-users] xen client side package.
To: jdsw2002@xxxxxxxxx
Cc: "XenUsers" <xen-users@xxxxxxxxxxxxxxxxxxx>
Date: Sunday, August 10, 2008, 8:37 PM
Hi Jd,

I think that ConVirt looks like it has a lot of potential,
but in my
personal experience, I haven't had very good luck with
it.

I have some included some suggestions and comments based on
your
questions below.

On Sun, Aug 10, 2008 at 11:04 PM, jd
<jdsw2002@xxxxxxxxx> wrote:
Hi
 As you might have noticed that ConVirt
http://www.convirt.net now supports  both Xen as well as KVM
platforms. I am looking for a smallest footprint xen client
package that can manage remote Xen Nodes via xml-rpc /
xen-api. This would help,


You should work with the Xen API team to make sure that you
have
included the proper xen-api
see:
http://wiki.xensource.com/xenwiki/XenApi

Yes, we would cut-over to use the XenAPI, but last time I looked it was not fully backed as well as resource constraints at our end is delaying this.

Still the API as separate rpm/installable entity is required.


   -- Xen users interested in managing Xen on the
remote box only

I frequently talk to many users (industry/academic/etc.)
that would
like to do this.


We allow this, but need whole xen installed... as there does not seem to be a good factoring for client side.

   -- KVM only users,

I don't think there would be a need to separate the
functionality,
unless there are
users that need a special case small installation size.

   -- and evaluating possibility of win32 ConVirt
client

I think this could lead to more widespread use of ConVirt.

On Fedora the xen-libs pacakge does not seem to
contain the python stuff while the xen package seems to
contain dependency on xen kernel, virt-* etc.
Also, would like to know distribution specific package
factoring for the same as well.

One of the biggest problems is that it, even with the
latest version
of ConVirt that I tried, requires a patched version of
Paramiko
and doesn't usually work well out of the box. It is
unclear from the
documentation alone why the patch is being applied.


This has nothing to do with the packaging on fedora right ? The paramiko had couple of bugs that got fixed in 1.7.3, so people who have 1.7.3, they do not have to do this. The patch takes care of detecting the version and doing the right thing, as 1.7.3 becomes wide spread, it wouldnt be necessary. For improving the doc, in case you missed, we have the ConVirt wiki, where everyone can participate and improve. This is going to be a big knowledge repository. check out at http://www.convirt.net/wiki



It should also be clearly stated in the docs what changes
that are
need to be made to the xend config file to get the remote
access to
work. Running the scripts should be done in the install (if
it is not
done that way already) and backups of the config files
should be made,
then just notify the user of the changes and give them a
way to roll
back the changes if needed to disable remote management.


Couple of observations, the changes to config file needs to be done on managed server which would be remote, and hence can not be done as a part of the install. For the local host management, this is not necessary. So out of the box, local management should work. On the other hand, people have been asking for scripts to do this, hence the scripts provided. The scripts also back up the original file.


If the basic functionality worked well out of the box, it
could
compete with virt-manager. A windows version could give it
an even
larger user base.

Also, last I knew there was an open bug [1] missing the
xenman/convirt
package. Ubuntu is a popular general purpose desktop and
having (minimally) remote support that works from that
would help the
user base too.

[1]
https://bugs.launchpad.net/ubuntu/+source/xen-meta/+bug/215558



Thanks for pointing this out... I will definitely follow up and see whats going on. I get emails on xenman/convirt issues... but not xen- desktop, this might be the reason why it got missed.

Thanks again for feedback, and anything else that you can do to help the project or documentation would be greatly appreciated.


/Jd
p.s. Just as note, this email does not address the actual problem of having a client side rpm that can be useful for doing remote xen management. So if anyone has ideas please let them out :)


Cheers,
Todd

--
Todd Deshane
http://todddeshane.net
check out our book: http://runningxen.com






------------------------------

Message: 4
Date: Thu, 07 Aug 2008 11:46:12 +1000
From: "Szabolcs Feczak" <sub@xxxxxxxxxxxxx>
Subject: [Xen-users] unsubscribe
To: <xen-users@xxxxxxxxxxxxxxxxxxx>
Message-ID: <489AE089.7432.000D.0@Adsl>




------------------------------

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


End of Xen-users Digest, Vol 42, Issue 65
*****************************************


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