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
*****************************************
Home