|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] Re: [Xen-devel] ARP problems with xen 4.0 with pvops kernel 2.6.32.15
On Wed, Jun 09, 2010 at 05:47:42AM -0700, Boris Derzhavets wrote: > I was able to virt-install F13 PV DomU in nographics mode under Xen > 4.0.1-rc2-pre (2.6.32.15 pvops c2cb3df04eb3ff68d0de102b2acacc9b8616e659) > at the point of extracting data from Apache mirror at Dom0 on top of > Ubuntu 10.04 ( text console mode message) > ------------------------------------------------- > 2 extracting cpio errors. Bad Magic > ------------------------------------------------- > However, virt-install proceeds further to promt "set up VNC at DomU" > and completed successfully. > VNC mode cannot pass through this extractions. It just hangs. > Yeah, there's something weird going on.. During the weekend I *think* I was successfully able to install guests when they didn't have vfb set up at all.. but when I set up vfb (ie. used virt-manager) the VM's started acting weird.. network problems, and problems in general, VM's freezing.. I haven't had time to confirm that yet.. -- Pasi > Boris. > > --- On Mon, 6/7/10, Pasi Kärkkäinen <pasik@xxxxxx> wrote: > > From: Pasi Kärkkäinen <pasik@xxxxxx> > Subject: Re: [Xen-users] Re: [Xen-devel] ARP problems with xen 4.0 with > pvops kernel 2.6.32.15 > To: "Boris Derzhavets" <bderzhavets@xxxxxxxxx> > Cc: "Jeremy Fitzhardinge" <jeremy@xxxxxxxx>, > xen-devel@xxxxxxxxxxxxxxxxxxx, luis.silva@xxxxxxxxxxxxx, > xen-users@xxxxxxxxxxxxxxxxxxx > Date: Monday, June 7, 2010, 3:55 AM > > On Sun, Jun 06, 2010 at 11:54:11AM -0700, Boris Derzhavets wrote: > > Virt-install hangs attempting to retrieve updates.img from Apache > Mirror > > setup at Dom0 > > with kernel 2.6.32.15 > > It doesn't happen with 2.6.32.10 (12,14 final). > > Environment Xen 4.0 Dom0 on top Ubuntu 10.04 Server. Libvirt is > 0.8.0 . > > Attempting to virt-install F13 PV DomU in vnc mode. > > > > I believe that builds are consistent. > > Runtime behavior is the same for .10, .14, .15. Seems to be > communicating > > problem between DomU and Dom0 during HTTP download. > > > > I'm seeing PV domU network issues aswell.. when running Xen 4.0.0 on > Fedora 13. > I'll have to dig more into it.. > > -- Pasi > > > Boris. > > > > --- On Sun, 6/6/10, Jeremy Fitzhardinge <[1]jeremy@xxxxxxxx> wrote: > > > > From: Jeremy Fitzhardinge <[2]jeremy@xxxxxxxx> > > Subject: Re: [Xen-users] Re: [Xen-devel] ARP problems with xen > 4.0 with > > pvops kernel 2.6.32.15 > > To: "Boris Derzhavets" <[3]bderzhavets@xxxxxxxxx> > > Cc: [4]luis.silva@xxxxxxxxxxxxx, > [5]xen-devel@xxxxxxxxxxxxxxxxxxx, > > [6]xen-users@xxxxxxxxxxxxxxxxxxx > > Date: Sunday, June 6, 2010, 12:43 PM > > > > On 06/06/2010 03:19 AM, Boris Derzhavets wrote: > > > Network issues when working with DomUs in 2.6.32.14 and finally > been > > > fixed, > > > seem to appear again in 2.6.32.15. Reverting to back to > xen/stable - > > > 2.6.32.10 > > > works as a fix again. > > > > > > > There are no substantial differences between 2.6.32.14 and .15. > If > > there are any differences in behaviour between them, then I'd > suspect > > some inconsistency from boot to boot, or in your kernel build > process. > > > > J > > > > > > > > Boris > > > > > > --- On *Thu, 6/3/10, Luís Silva > /<[1][7]luis.silva@xxxxxxxxxxxxx>/* > > wrote: > > > > > > > > > From: Luís Silva <[2][8]luis.silva@xxxxxxxxxxxxx> > > > Subject: Re: [Xen-users] Re: [Xen-devel] ARP problems with > xen 4.0 > > > with pvops kernel > > > To: "Boris Derzhavets" <[3][9]bderzhavets@xxxxxxxxx> > > > Cc: "Jeremy Fitzhardinge" <[4][10]jeremy@xxxxxxxx>, > > > [5][11]xen-devel@xxxxxxxxxxxxxxxxxxx, > [6][12]xen-users@xxxxxxxxxxxxxxxxxxx > > > Date: Thursday, June 3, 2010, 6:20 AM > > > > > > Hello, > > > > > > Thanks for the suggestion, xen/stable works ok for me. Only > > > problem is that I have to disable offload do get dhcp to > work on > > > domU, but the problem I described before doesn't exist in > this > > > kernel. Later today I'm going to try a previous build I > have based > > > on stable-2.6.32.x (2.6.32.13) to check if it already had > this > > > problem or not and I'll post the results. > > > > > > Luís > > > > > > On Wed, 2010-06-02 at 12:26 -0700, Boris Derzhavets wrote: > > >> Could you,please, build and try 2.6.32.10 ( xen/stable) ? > > >> > > >> Boris. > > >> > > >> --- On *Wed, 6/2/10, Luís Silva > > **/<[7][13]luis.silva@xxxxxxxxxxxxx>/* > > >> wrote: > > >> > > >> > > >> From: Luís Silva <[8][14]luis.silva@xxxxxxxxxxxxx> > > >> Subject: [Xen-users] Re: [Xen-devel] ARP problems with > xen > > >> 4.0 with pvops kernel > > >> To: "Jeremy Fitzhardinge" <[9][15]jeremy@xxxxxxxx> > > >> Cc: [10][16]xen-devel@xxxxxxxxxxxxxxxxxxx, > > [11][17]xen-users@xxxxxxxxxxxxxxxxxxx > > >> Date: Wednesday, June 2, 2010, 2:53 PM > > >> > > >> Hello, > > >> > > >> On Wed, 2010-06-02 at 09:06 -0700, Jeremy Fitzhardinge > wrote: > > >>> On 06/02/2010 01:47 AM, Luís Silva wrote: > > >>> > Hello, > > >>> > > > >>> > I'm using the latest stable-2.6.32.x. I already > tried > > "ethtool -K > > >>> > <bridge> tx off", but that didn't make any > difference. > > Also, this only > > >>> > happen with pv, in hvm mode all works ok and the > domU sees > > the arp > > >>> > messages... > > >>> > > >>> Yes, ARP is a new twist on network problems. I'm > guessing > > you're using > > >>> hvm without stubdoms, which means that its networking > > originates from > > >>> qemu within dom0, whereas PV and HVM+stubdom comes > via > > netback. > > >>> > > >>> > > >> Yes, when I mentioned hvm I was talking about hvm > without > > >> stubdoms. I haven't tried those yet. > > >>> But aside from that, I'm stumped. Are you running > any > > firewalls on > > >>> either side? Can you try disabling all the offloads > (tx, > > rx, gso, tso) > > >>> on all the relevent interfaces (bridge, netback, > within the > > guest) and > > >>> see if that changes anything? > > >>> > > >>> J > > >>> > > >>> > > >> > > >> Ok, this is the bridge interface: > > >> > > >> brctl show > > >> bridge name bridge id STP enabled > interfaces > > >> virbr0 8000.feffffffffff no vif1.0 > > >> > > >> ifconfig virbr0 > > >> virbr0 Link encap:Ethernet HWaddr > c2:ef:67:2b:a4:23 > > >> inet addr:192.168.120.254 > Bcast:192.168.120.255 > > Mask:255.255.255.0 > > >> inet6 addr: fe80::c0ef:67ff:fe2b:a423/64 > Scope:Link > > >> UP BROADCAST RUNNING MULTICAST MTU:1500 > Metric:1 > > >> RX packets:0 errors:0 dropped:0 overruns:0 > frame:0 > > >> TX packets:25 errors:0 dropped:0 overruns:0 > > carrier:0 > > >> collisions:0 txqueuelen:0 > > >> RX bytes:0 (0.0 > > >> B) > > >> TX bytes:4662 (4.6 KB) > > >> > > >> > > >> > > >> I'm not using firewall other than the rules defined by > > >> libvirt. DomU has no firewall and the rules in dom0 > are only > > >> these (virbr0 is natted to the outside, virbr1 is > routed. The > > >> result is the same in either one of them): > > >> > > >> sudo iptables -L -n -v > > >> Chain INPUT (policy ACCEPT 241K packets, 53M bytes) > > >> pkts bytes target prot opt in out source > > destination > > >> 0 0 ACCEPT udp -- virbr1 * > 0.0.0.0/0 > > 0.0.0.0/0 udp dpt:53 > > >> 0 0 ACCEPT tcp -- virbr1 * > 0.0.0.0/0 > > 0.0.0.0/0 tcp dpt:53 > > >> > > >> > > >> 0 0 ACCEPT udp -- virbr1 * > 0.0.0.0/0 > > 0.0.0.0/0 udp dpt:67 > > >> 0 0 ACCEPT tcp -- virbr1 * > 0.0.0.0/0 > > 0.0.0.0/0 tcp dpt:67 > > >> 8 515 ACCEPT udp -- virbr0 * > 0.0.0.0/0 > > 0.0.0.0/0 udp dpt:53 > > >> 0 0 > > >> > > >> ACCEPT tcp -- virbr0 * 0.0.0.0/0 > > 0.0.0.0/0 tcp dpt:53 > > >> 0 0 ACCEPT udp -- virbr0 * > 0.0.0.0/0 > > 0.0.0.0/0 udp dpt:67 > > >> 0 0 ACCEPT tcp -- virbr0 * > 0.0.0.0/0 > > 0.0.0.0/0 tcp dpt:67 > > >> > > >> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) > > >> pkts bytes target > > >> prot > > >> opt in out source destination > > >> 0 0 ACCEPT all -- * virbr1 > 0.0.0.0/0 > > 192.168.121.0/24 > > >> 0 0 ACCEPT all -- virbr1 * > > 192.168.121.0/24 0.0.0.0/0 > > >> 0 0 ACCEPT all -- virbr1 virbr1 > 0.0.0.0/0 > > > > >> > > >> 0.0.0.0/0 > > >> 0 0 REJECT all -- * virbr1 > 0.0.0.0/0 > > 0.0.0.0/0 reject-with icmp-port-unreachable > > >> 0 0 REJECT all -- virbr1 * > 0.0.0.0/0 > > 0.0.0.0/0 reject-with icmp-port-unreachable > > >> 13 3448 ACCEPT all -- * virbr0 > 0.0.0.0/0 > > 192.168.120.0/24 > > >> state > > >> RELATED,ESTABLISHED > > >> 16 1374 ACCEPT all -- virbr0 * > > 192.168.120.0/24 0.0.0.0/0 > > >> 0 0 ACCEPT all -- virbr0 virbr0 > 0.0.0.0/0 > > 0.0.0.0/0 > > >> 0 0 REJECT all -- * virbr0 > 0.0.0.0/0 > > 0.0.0.0/0 reject-with icmp-port-unreachable > > >> 0 0 REJECT all -- > > >> virbr0 > > >> * 0.0.0.0/0 0.0.0.0/0 > reject-with > > icmp-port-unreachable > > >> > > >> Chain OUTPUT (policy ACCEPT 233K packets, 27M bytes) > > >> pkts bytes target prot opt in out source > > destination > > >> > > >> > > >> > > >> > > >> And these are the various offload parameters as set at > boot: > > >> > > >> Offload parameters for virbr0: > > >> rx-checksumming: on > > >> tx-checksumming: on > > >> scatter-gather: on > > >> tcp-segmentation-offload: on > > >> udp-fragmentation-offload: on > > >> generic-segmentation-offload: on > > >> generic-receive-offload: off > > >> large-receive-offload: off > > >> > > >> Offload parameters for vif1.0: > > >> rx-checksumming: on > > >> tx-checksumming: on > > >> scatter-gather: on > > >> tcp-segmentation-offload: on > > >> udp-fragmentation-offload: off > > >> generic-segmentation-offload: on > > >> generic-receive-offload: off > > >> large-receive-offload: off > > >> > > >> Offload parameters for eth0: > > >> rx-checksumming: on > > >> tx-checksumming: on > > >> scatter-gather: on > > >> tcp-segmentation-offload: on > > >> udp-fragmentation-offload: off > > >> generic-segmentation-offload: off > > >> generic-receive-offload: off > > >> large-receive-offload: off > > >> > > >> > > >> > > >> To disable all checksuming I run the following > commands: > > >> dom0: > > >> > > >> sudo ethtool -K virbr0 tx off sg off tso off gso off > gro off > > >> sudo ethtool -K vif1.0 tx off sg off tso off gso off > gro off > > >> > > >> > > >> domU > > >> > > >> sudo ethtool -K eth0 tx off sg off tso off gso off gro > off > > >> > > >> > > >> > > >> This managed to get all parameter to off in the > mentioned > > >> interfaces, but unfortunately the result is the same. > The arp > > >> requests get to vif1.0, but not to eth0 on the domU. > > >> > > >> sudo tcpdump -i vif1.0 -n -vv arp > > >> tcpdump: WARNING: vif1.0: no IPv4 address assigned > > >> tcpdump: listening on vif1.0, link-type EN10MB > (Ethernet), > > capture size 96 bytes > > >> 19:43:51.233378 ARP, Ethernet (len 6), IPv4 (len 4), > Request > > who-has 192.168.120.1 tell 192.168.120.254, length 28 > > >> 19:43:52.233164 ARP, Ethernet (len 6), IPv4 (len 4), > Request > > who-has 192.168.120.1 tell 192.168.120.254, length 28 > > >> 19:43:53.233166 ARP, Ethernet (len 6), IPv4 (len 4), > Request > > who-has 192.168.120.1 tell 192.168.120.254, length 28 > > >> 19:43:54.684214 ARP, Ethernet (len 6), IPv4 (len 4), > Request > > who-has 192.168.120.1 tell 192.168.120.254, length 28 > > >> 19:43:55.684218 ARP, Ethernet (len 6), IPv4 (len 4), > Request > > who-has 192.168.120.1 tell 192.168.120.254, length 28 > > >> 19:43:56.684232 ARP, Ethernet (len 6), IPv4 (len 4), > Request > > who-has 192.168.120.1 tell 192.168.120.254, length 28 > > >> > > >> > > >> > > >> I hope this information is enough. If I can provide > anything > > >> else to help debug or test, please just ask! ;) > > >> > > >> Thanks in advance, > > >> Luís > > >> > > >>> > > > >>> > Thanks, > > >>> > Luís > > >>> > > > >>> > On Tue, 2010-06-01 at 18:20 -0700, Jeremy > Fitzhardinge > > wrote: > > >>> >> On 06/01/2010 05:38 PM, Luís Silva wrote: > > >>> >> > Hello, > > >>> >> > > > >>> >> > Finally I managed to get a xen 4.0 working on > ubuntu > > 10.04 with pvops > > >>> >> > kernel and libvirt. However I am having some > problems > > with > > >>> >> > networking... after initial installation with > > netinstall image in hvm > > >>> >> > mode, when I transform the vm in xen pv (via > pygrub > > with the current > > >>> >> > ubuntu kernel), networking startEd to act > weird... > > >>> >> > > > >>> >> > Basically I'm not using a network script from > xen. I > > define a bridge > > >>> >> > (manually or via libvirt, the result is the > same) and I > > use vif-bridge > > >>> >> > to connect the vif to it. But now the weird part > comes: > > I can > > >>> >> > communicate from domU to dom0, but not the other > way > > >>> around, > > >>> unless I > > >>> >> > keep a ping running from domU to dom0... That's > right, > > weird... while > > >>> >> > trying the ping from dom0 to domU, I used > tcpdump both > > on the bridge, > > >>> >> > on the vif and on the eth0 in the domU. The arp > packets > > never get to > > >>> >> > domU, but they appear both in the bridge and the > vif > > sniff's... > > >>> >> > > >>> >> What version of kernel are you using in dom0 and > domU? > > There was a > > >>> >> netback bug which caused problems with dom0<->domU > > communication, but it > > >>> >> has been fixed for a while in 2.6.32 (but only > recently > > in .31). The > > >>> >> workaround is to disable tx checksum offload on > your > > bridge (ethtool -K > > >>> >> <bridge> tx off). > > >>> >> > > >>> >> J > > >>> >> > > >>> >> > > > >>> >> > Here is the bridge: > > >>> >> > ifconfig virbr0 > > >>> >> > virbr0 Link encap:Ethernet HWaddr > > fe:ff:ff:ff:ff:ff > > >>> >> > > > >>> > > >>> inet addr:192.168.120.254 Bcast:192.168.120.255 > > Mask:255.255.255.0 > > >>> >> > inet6 addr: > fe80::7cee:4bff:fe82:e63f/64 > > Scope:Link > > >>> >> > UP BROADCAST RUNNING MULTICAST > MTU:1500 > > Metric:1 > > >>> >> > RX packets:16 errors:0 dropped:0 > overruns:0 > > frame:0 > > >>> >> > TX packets:226 errors:0 dropped:0 > overruns:0 > > carrier:0 > > >>> >> > collisions:0 txqueuelen:0 > > >>> >> > RX bytes:952 (952.0 B) TX bytes:13953 > (13.9 > > KB) > > >>> >> > > > >>> >> > > > >>> >> > brctl show > > >>> >> > bridge name bridge id STP enabled > > interfaces > > >>> >> > virbr0 8000.feffffffffff no > vif5.0 > > >>> >> > > > >>> >> > > > >>> >> > tcpdump -i virbr0 -vv -n > > >>> >> > tcpdump: listening on virbr0, link-type EN10MB > > (Ethernet), capture size 96 bytes > > >>> >> > 01:31:25.945151 IP (tos 0x0, ttl 64, id 0, > offset 0, > > flags [DF], > > >>> proto ICMP (1), > > >>> length 84) > > >>> >> > 192.168.120.254 > 192.168.120.1: ICMP echo > request, > > id 10317, seq 1, length 64 > > >>> >> > 01:31:26.945361 IP (tos 0x0, ttl 64, id 0, > offset 0, > > flags [DF], proto ICMP (1), length 84) > > >>> >> > 192.168.120.254 > 192.168.120.1: ICMP echo > request, > > id 10317, seq 2, length 64 > > >>> >> > 01:31:27.945420 IP (tos 0x0, ttl 64, id 0, > offset 0, > > flags [DF], proto ICMP (1), length 84) > > >>> >> > 192.168.120.254 > 192.168.120.1: ICMP echo > request, > > id 10317, seq 3, length 64 > > >>> >> > 01:31:28.945362 IP (tos 0x0, ttl 64, id 0, > offset 0, > > flags [DF], proto ICMP (1), length 84) > > >>> >> > 192.168.120.254 > 192.168.120.1: ICMP echo > request, > > id 10317, seq 4, length 64 > > >>> >> > 01:31:29.945364 IP (tos 0x0, ttl 64, id 0, > offset 0, > > flags [DF], proto ICMP (1), length 84) > > >>> >> > 192.168.120.254 > 192.168.120.1: ICMP echo > request, > > id 10317, > > >>> seq 5, length > > >>> 64 > > >>> >> > 01:31:30.944300 ARP, Ethernet (len 6), IPv4 (len > 4), > > Request who-has 192.168.120.1 tell 192.168.120.254, length 28 > > >>> >> > 01:31:30.945359 IP (tos 0x0, ttl 64, id 0, > offset 0, > > flags [DF], proto ICMP (1), length 84) > > >>> >> > 192.168.120.254 > 192.168.120.1: ICMP echo > request, > > id 10317, seq 6, length 64 > > >>> >> > 01:31:31.944297 ARP, Ethernet (len 6), IPv4 (len > 4), > > Request who-has 192.168.120.1 tell 192.168.120.254, length 28 > > >>> >> > 01:31:31.945444 IP (tos 0x0, ttl 64, id 0, > offset 0, > > flags [DF], proto ICMP (1), length 84) > > >>> >> > 192.168.120.254 > 192.168.120.1: ICMP echo > request, > > id 10317, seq 7, length 64 > > >>> >> > 01:31:32.944294 ARP, Ethernet (len 6), IPv4 (len > 4), > > Request who-has 192.168.120.1 tell 192.168.120.254, length 28 > > >>> >> > 01:31:32.945401 IP (tos 0x0, ttl 64, id 0, > offset 0, > > flags [DF], proto ICMP (1), length 84) > > >>> >> > > > >>> > > >>> 192.168.120.254 > 192.168.120.1: ICMP echo request, > id > > 10317, seq 8, length 64 > > >>> >> > 01:31:33.947293 ARP, Ethernet (len 6), IPv4 (len > 4), > > Request who-has 192.168.120.1 tell 192.168.120.254, length 28 > > >>> >> > 01:31:34.947373 ARP, Ethernet (len 6), IPv4 (len > 4), > > Request who-has 192.168.120.1 tell 192.168.120.254, length 28 > > >>> >> > 01:31:35.947353 ARP, Ethernet (len 6), IPv4 (len > 4), > > Request who-has 192.168.120.1 tell 192.168.120.254, length 28 > > >>> >> > 01:31:37.948352 ARP, Ethernet (len 6), IPv4 (len > 4), > > Request who-has 192.168.120.1 tell 192.168.120.254, length 28 > > >>> >> > 01:31:38.948399 ARP, Ethernet (len 6), IPv4 (len > 4), > > Request who-has 192.168.120.1 tell 192.168.120.254, length 28 > > >>> >> > 01:31:39.948376 ARP, Ethernet (len 6), IPv4 (len > 4), > > Request who-has 192.168.120.1 tell 192.168.120.254, length 28 > > >>> >> > 01:31:40.949356 ARP, Ethernet (len 6), IPv4 (len > 4), > > Request > > >>> who-has > > >>> 192.168.120.1 tell 192.168.120.254, length 28 > > >>> >> > > > >>> >> > > > >>> >> > tcpdump -i vif5.0 -vv -n > > >>> >> > tcpdump: WARNING: vif5.0: no IPv4 address > assigned > > >>> >> > tcpdump: listening on vif5.0, link-type EN10MB > > (Ethernet), capture size 96 bytes > > >>> >> > 01:32:19.956358 ARP, Ethernet (len 6), IPv4 (len > 4), > > Request who-has 192.168.120.1 tell 192.168.120.254, length 28 > > >>> >> > 01:32:20.956358 ARP, Ethernet (len 6), IPv4 (len > 4), > > Request who-has 192.168.120.1 tell 192.168.120.254, length 28 > > >>> >> > 01:32:21.956359 ARP, Ethernet (len 6), IPv4 (len > 4), > > Request who-has 192.168.120.1 tell 192.168.120.254, length 28 > > >>> >> > 01:32:23.957311 ARP, Ethernet (len 6), IPv4 (len > 4), > > Request who-has 192.168.120.1 tell 192.168.120.254, length 28 > > >>> >> > 01:32:24.957312 ARP, Ethernet (len 6), IPv4 (len > 4), > > Request who-has 192.168.120.1 tell 192.168.120.254, length > > >>> 28 > > >>> >> > > > >>> 01:32:25.957359 ARP, Ethernet (len 6), IPv4 (len 4), > > Request who-has 192.168.120.1 tell 192.168.120.254, length 28 > > >>> >> > 01:32:27.958360 ARP, Ethernet (len 6), IPv4 (len > 4), > > Request who-has 192.168.120.1 tell 192.168.120.254, length 28 > > >>> >> > 01:32:28.958310 ARP, Ethernet (len 6), IPv4 (len > 4), > > Request who-has 192.168.120.1 tell 192.168.120.254, length 28 > > >>> >> > 01:32:29.958362 ARP, Ethernet (len 6), IPv4 (len > 4), > > Request who-has 192.168.120.1 tell 192.168.120.254, length 28 > > >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > Forwarding and iptables don't seem to be the > problem, > > because if I > > >>> >> > initiate a ping from domU (at the same time as > the > > failing one from > > >>> >> > dom0), the ping in dom0 starts to work. As soon > as I > > stop the ping in > > >>> >> > domU, the one in dom0 starts failing again... > > >>> >> > > > >>> >> > Is anyone having the same > > >>> problem? Is this a bug > > >>> in the kernel? In > > >>> >> > dom0 or domU? > > >>> >> > > > >>> >> > Thanks in advance, > > >>> >> > Luís > > >>> >> > > > >>> >> > > > >>> >> > _______________________________________________ > > >>> >> > Xen-devel mailing list > > >>> >> > [12][18]Xen-devel@xxxxxxxxxxxxxxxxxxx > > <mailto:[13][19]Xen-devel@xxxxxxxxxxxxxxxxxxx> > > <mailto:[14][20]Xen-devel@xxxxxxxxxxxxxxxxxxx> > > >>> >> > [15][21]http://lists.xensource.com/xen-devel > > >>> >> > > > >>> >> > > >>> >> > > >>> >> _______________________________________________ > > >>> >> Xen-devel mailing list > > >>> >> [16][22]Xen-devel@xxxxxxxxxxxxxxxxxxx > > <mailto:[17][23]Xen-devel@xxxxxxxxxxxxxxxxxxx> > > <mailto:[18][24]Xen-devel@xxxxxxxxxxxxxxxxxxx> > > >>> >> [19][25]http://lists.xensource.com/xen-devel > > >>> >> > > >>> >> > > >>> > > > >>> > > >>> > > >>> > > >> > > >> > > >> > > >> -----Inline Attachment Follows----- > > >> > > >> _______________________________________________ > > >> Xen-users mailing list > > >> [20][26]Xen-users@xxxxxxxxxxxxxxxxxxx > > >> [21][27]http://lists.xensource.com/xen-users > > >> > > >> > > > > > > > > > -----Inline Attachment Follows----- > > > > > > _______________________________________________ > > > Xen-users mailing list > > > [22][28]Xen-users@xxxxxxxxxxxxxxxxxxx > > > </mc/compose?to=[23][29]Xen-users@xxxxxxxxxxxxxxxxxxx> > > > [24][30]http://lists.xensource.com/xen-users > > > > > > > > > > References > > > > Visible links > > 1. file:///mc/compose?to=[31]luis.silva@xxxxxxxxxxxxx > > 2. file:///mc/compose?to=[32]luis.silva@xxxxxxxxxxxxx > > 3. file:///mc/compose?to=[33]bderzhavets@xxxxxxxxx > > 4. file:///mc/compose?to=[34]jeremy@xxxxxxxx > > 5. file:///mc/compose?to=[35]xen-devel@xxxxxxxxxxxxxxxxxxx > > 6. file:///mc/compose?to=[36]xen-users@xxxxxxxxxxxxxxxxxxx > > 7. file:///mc/compose?to=[37]luis.silva@xxxxxxxxxxxxx > > 8. file:///mc/compose?to=[38]luis.silva@xxxxxxxxxxxxx > > 9. file:///mc/compose?to=[39]jeremy@xxxxxxxx > > 10. file:///mc/compose?to=[40]xen-devel@xxxxxxxxxxxxxxxxxxx > > 11. file:///mc/compose?to=[41]xen-users@xxxxxxxxxxxxxxxxxxx > > 12. file:///mc/compose?to=[42]Xen-devel@xxxxxxxxxxxxxxxxxxx > > 13. file:///mc/compose?to=[43]Xen-devel@xxxxxxxxxxxxxxxxxxx > > 14. file:///mc/compose?to=[44]Xen-devel@xxxxxxxxxxxxxxxxxxx > > 15. [45]http://lists.xensource.com/xen-devel > > 16. file:///mc/compose?to=[46]Xen-devel@xxxxxxxxxxxxxxxxxxx > > 17. file:///mc/compose?to=[47]Xen-devel@xxxxxxxxxxxxxxxxxxx > > 18. file:///mc/compose?to=[48]Xen-devel@xxxxxxxxxxxxxxxxxxx > > 19. [49]http://lists.xensource.com/xen-devel > > 20. file:///mc/compose?to=[50]Xen-users@xxxxxxxxxxxxxxxxxxx > > 21. [51]http://lists.xensource.com/xen-users > > 22. file:///mc/compose?to=[52]Xen-users@xxxxxxxxxxxxxxxxxxx > > 23. file:///mc/compose?to=[53]Xen-users@xxxxxxxxxxxxxxxxxxx > > 24. [54]http://lists.xensource.com/xen-users > > > _______________________________________________ > > Xen-devel mailing list > > [55]Xen-devel@xxxxxxxxxxxxxxxxxxx > > [56]http://lists.xensource.com/xen-devel > > _______________________________________________ > Xen-devel mailing list > [57]Xen-devel@xxxxxxxxxxxxxxxxxxx > [58]http://lists.xensource.com/xen-devel > > References > > Visible links > 1. file:///mc/compose?to=jeremy@xxxxxxxx > 2. file:///mc/compose?to=jeremy@xxxxxxxx > 3. file:///mc/compose?to=bderzhavets@xxxxxxxxx > 4. file:///mc/compose?to=luis.silva@xxxxxxxxxxxxx > 5. file:///mc/compose?to=xen-devel@xxxxxxxxxxxxxxxxxxx > 6. file:///mc/compose?to=xen-users@xxxxxxxxxxxxxxxxxxx > 7. file:///mc/compose?to=luis.silva@xxxxxxxxxxxxx > 8. file:///mc/compose?to=luis.silva@xxxxxxxxxxxxx > 9. file:///mc/compose?to=bderzhavets@xxxxxxxxx > 10. file:///mc/compose?to=jeremy@xxxxxxxx > 11. file:///mc/compose?to=xen-devel@xxxxxxxxxxxxxxxxxxx > 12. file:///mc/compose?to=xen-users@xxxxxxxxxxxxxxxxxxx > 13. file:///mc/compose?to=luis.silva@xxxxxxxxxxxxx > 14. file:///mc/compose?to=luis.silva@xxxxxxxxxxxxx > 15. file:///mc/compose?to=jeremy@xxxxxxxx > 16. file:///mc/compose?to=xen-devel@xxxxxxxxxxxxxxxxxxx > 17. file:///mc/compose?to=xen-users@xxxxxxxxxxxxxxxxxxx > 18. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx > 19. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx > 20. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx > 21. http://lists.xensource.com/xen-devel > 22. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx > 23. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx > 24. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx > 25. http://lists.xensource.com/xen-devel > 26. file:///mc/compose?to=Xen-users@xxxxxxxxxxxxxxxxxxx > 27. http://lists.xensource.com/xen-users > 28. file:///mc/compose?to=Xen-users@xxxxxxxxxxxxxxxxxxx > 29. file:///mc/compose?to=Xen-users@xxxxxxxxxxxxxxxxxxx > 30. http://lists.xensource.com/xen-users > 31. file:///mc/compose?to=luis.silva@xxxxxxxxxxxxx > 32. file:///mc/compose?to=luis.silva@xxxxxxxxxxxxx > 33. file:///mc/compose?to=bderzhavets@xxxxxxxxx > 34. file:///mc/compose?to=jeremy@xxxxxxxx > 35. file:///mc/compose?to=xen-devel@xxxxxxxxxxxxxxxxxxx > 36. file:///mc/compose?to=xen-users@xxxxxxxxxxxxxxxxxxx > 37. file:///mc/compose?to=luis.silva@xxxxxxxxxxxxx > 38. file:///mc/compose?to=luis.silva@xxxxxxxxxxxxx > 39. file:///mc/compose?to=jeremy@xxxxxxxx > 40. file:///mc/compose?to=xen-devel@xxxxxxxxxxxxxxxxxxx > 41. file:///mc/compose?to=xen-users@xxxxxxxxxxxxxxxxxxx > 42. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx > 43. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx > 44. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx > 45. http://lists.xensource.com/xen-devel > 46. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx > 47. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx > 48. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx > 49. http://lists.xensource.com/xen-devel > 50. file:///mc/compose?to=Xen-users@xxxxxxxxxxxxxxxxxxx > 51. http://lists.xensource.com/xen-users > 52. file:///mc/compose?to=Xen-users@xxxxxxxxxxxxxxxxxxx > 53. file:///mc/compose?to=Xen-users@xxxxxxxxxxxxxxxxxxx > 54. http://lists.xensource.com/xen-users > 55. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx > 56. http://lists.xensource.com/xen-devel > 57. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx > 58. http://lists.xensource.com/xen-devel _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |