[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [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=newticketNew 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 twoguest domains running (1 win2k3 and 1 Centos Linux), and it seems to only affect the windows guest. The event log on the guest server showsnothing unusual (in fact it appears to be functioning normally based onCPU 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 multicastgroup 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 stateAug 11 10:32:30 vs-001 kernel: device vif6.0 entered promiscuous modeAug 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 thatguest keeps going down? Is there a fundamental problem with the currentnetwork 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 DomU2. Assign the subnet gateway to the domU, above vuf configuration isfine 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 agateway 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 domUensure 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 -nifconfig 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 UseIface192.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 lo2. dom0 ifconfig & route -ndom0 ifconfig has the following result : dummy0 Link encap:Ethernet HWaddr 52:B0:12:64:EA:DDinet addr:10.33.195.40 Bcast:10.33.195.255 Mask: 255.255.255.0inet6 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:4Ainet addr:10.33.196.47 Bcast:10.33.196.255 Mask: 255.255.255.0inet6 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:4Ainet addr:192.168.1.255 Bcast:10.33.196.255 Mask: 255.255.255.0UP 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 tableDestination Gateway Genmask Flags Metric Ref UseIface10.33.195.0 0.0.0.0 255.255.255.0 U 0 0 0dummy010.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 eth03. brctl showbrctl on dom0 gives the following output: xenbr0 8000.9ea2fe02921d no vif0.0 pdummy0 tap0 vif10.0Since 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.-tejis there any method to know that the eth0 of domU is connected to xenbr0one more information that i missed out last time was that i am usingfullvirtualization. so i just want to confirm that are the above steps finefor 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 ConVirthttp://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/XenApiYes, 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 theremote 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 ConVirtclient I think this could lead to more widespread use of ConVirt.On Fedora the xen-libs pacakge does not seem tocontain the python stuff while the xen package seems to contain dependency on xen kernel, virt-* etc.Also, would like to know distribution specific packagefactoring 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/wikiIt 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/215558Thanks 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./Jdp.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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |