John @ New Frontiers
2008-Aug-11 16:24 UTC
[Xen-users] Re: Xen-users Digest, Vol 42, Issue 65
__________ 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@lists.xensource.com wrote:> Send Xen-users mailing list submissions to > xen-users@lists.xensource.com > > 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@lists.xensource.com > > You can reach the person managing the list at > xen-users-owner@lists.xensource.com > > 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@ssaihq.com> > Subject: [Xen-users] tap interface shuts down for unknown reasons > To: xen-users@lists.xensource.com > Message-ID: <48A05B5E.8010904@ssaihq.com> > 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@gmail.com> > Subject: Re: [Xen-users] Re: DomU network configuration problem > To: shubham <shubham.sharma@hcl.in> > Cc: xen-users@lists.xensource.com > Message-ID: > <f1c9d250808110849t74d2e964j5be0f2ec228a82e5@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 8/11/08, shubham <shubham.sharma@hcl.in> 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@lists.xensource.com >> http://lists.xensource.com/xen-users >> > > > > ------------------------------ > > Message: 3 > Date: Mon, 11 Aug 2008 09:06:42 -0700 (PDT) > From: jd <jdsw2002@yahoo.com> > Subject: Re: [Xen-users] xen client side package. > To: deshantm@gmail.com > Cc: XenUsers <xen-users@lists.xensource.com> > Message-ID: <61824.44774.qm@web35801.mail.mud.yahoo.com> > Content-Type: text/plain; charset=us-ascii > > Todd, > Thanks for detailed feedback... see inline... > > > --- On Sun, 8/10/08, Todd Deshane <deshantm@gmail.com> wrote: > >> From: Todd Deshane <deshantm@gmail.com> >> Subject: Re: [Xen-users] xen client side package. >> To: jdsw2002@yahoo.com >> Cc: "XenUsers" <xen-users@lists.xensource.com> >> 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@yahoo.com> 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@symsol.com.au> > Subject: [Xen-users] unsubscribe > To: <xen-users@lists.xensource.com> > Message-ID: <489AE089.7432.000D.0@Adsl> > > > > > ------------------------------ > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users > > > End of Xen-users Digest, Vol 42, Issue 65 > *****************************************_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users