thr3ads.net - Xen users - [Xen-users] Re: [Xen-devel] xen 4.1.2* dhcp issue/bug when installing/booting HVM domU domains (CentOS 6, unbuntu 11.04 server). Debian/OpenSolaris work fine. [Aug 2011]

If this information is useful, please help other people find it:
Share via:

Mark Schneider

2011-Aug-15 21:12 UTC

[Xen-users] Re: [Xen-devel] xen 4.1.2* dhcp issue/bug when installing/booting HVM domU domains (CentOS 6, unbuntu 11.04 server). Debian/OpenSolaris work fine.

Thanks a lot for your hints Pasi.

Due to your suggestion I open a new thread here.

I have tested with model=e1000 (HVMs). As HVM configs are identical (not 
iso images and LVM volumes) I guess it is a xen 4.1.2* issue .. or just 
involved domU OS-kernels (however as it is HVM it should not play any role)

Tested and correctly working OSes (getting an IP address and pinging of 
"external" IPs):
- debian squeeze
- debian wheezy
- OpenSolaris (live mode)

Tested and *nonworking* working OSes (no IP address):
- CentOS 6.0

# ---
Name                                        ID   Mem VCPUs      State   
Time(s)
Domain-0                                     0  1536     2     r-----   
1063.7
centoshvm.born2b3.net                        5  8192     4     
-b----     41.9
netbsdhvm.born2b3.net                        7  4096     2     
-b----     17.6
opensolarishvm.born2b3.net                   3  4096     2     -b----    
179.6
# ---


Pings from *centos-hvm* to dom0 interface*no ip-traffic on peth0*
# ---
root@xen411dom0:/ftp/HVM# tcpdump  ''icmp[icmptype] = icmp-echo and 
icmp[icmptype] != icmp-echoreply''
tcpdump: WARNING: peth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on peth0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
0 packets captured
6 packets received by filter
0 packets dropped by kernel


root@xen411dom0:/ftp/HVM# tcpdump  -i eth0 ''icmp[icmptype] = icmp-echo 
and icmp[icmptype] != icmp-echoreply''
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
19:45:30.283679 IP 192.168.1.180 > 192.168.1.124: ICMP echo request, id 
61445, seq 23, length 64
19:45:31.285560 IP 192.168.1.180 > 192.168.1.124: ICMP echo request, id 
61445, seq 24, length 64
# ---

Pings from *centos-hvm* to default gateway *no ip-traffic on peth0*
# ---
root@xen411dom0:/ftp/HVM# tcpdump  ''icmp[icmptype] = icmp-echo and 
icmp[icmptype] != icmp-echoreply''
tcpdump: WARNING: peth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on peth0, link-type EN10MB (Ethernet), capture size 65535 bytes

^C
0 packets captured
6 packets received by filter
0 packets dropped by kernel


root@xen411dom0:/ftp/HVM# tcpdump  -i eth0 ''icmp[icmptype] = icmp-echo 
and icmp[icmptype] != icmp-echoreply''
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
19:54:00.770442 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
518, seq 23, length 64
19:54:01.770958 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
518, seq 24, length 64
# ---

OpenSolaris HVM (live mode) works as expected:
# ---
Sun Microsystems Inc.   SunOS 5.11      snv_111b        November 2008
root@opensolaris:~#

root@opensolaris:~# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 
8232 index 1
         inet 127.0.0.1 netmask ff000000
e1000g0: flags=1004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4> mtu 
1500 index 2
         inet 0.0.0.0 netmask ff000000
         ether 0:16:3e:27:20:67
xnf0: flags=1004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4> mtu 1500 
index 3
         inet 192.168.1.100 netmask ffffff00 broadcast 192.168.1.255
         ether 0:16:3e:27:20:67
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 
8252 index 1
         inet6 ::1/128
xnf0: flags=2004841<UP,RUNNING,MULTICAST,DHCP,IPv6> mtu 1500 index 3
         inet6 fe80::216:3eff:fe27:2067/10
         ether 0:16:3e:27:20:67

root@opensolaris:~# ping 192.168.1.1
192.168.1.1 is alive
# ---

How can I debug why I can see ICMP or dhcp packages on eth0 (dom0) but 
not peth0?

Thank you in advance for any hints.

regards, Mark


Am 14.08.2011 16:33, schrieb Pasi Kärkkäinen:> This is probably something for xen-users mailinglist instead..
> It sounds like a configuration problem to me.
>
>
>    On Sun, Aug 14, 2011 at 03:52:57PM +0200, Mark Schneider wrote:
>> As there are quite a lot of involved details I would use links to keep
>> better overview of the problem.
>>
>> The problem is that CentOS (tested with 6.0) and ubuntu (tested with
>> 11.04 server) *can''t get* an IP address during the
installation of HVMs.
>> I had the same problem with NetBSD 5.1 however didn''t repeat
this test
>> yesterday again. I have tested with "model=e1000" and
"model=rtl8139"
>> (s. the HVM config file below)
>>
http://www.it-infrastrukturen.com/fileadmin/linux/paste/xen-centos-issues/hvm-centos1Gbit.born2b3.net.cfg
>>
>>
>> Debian''s squeeze and wheezy images *don''t have this
issue* and are
>> getting an IP address (dhpc) during the installation and booting.
>>
>> The following text describes the test with CentOS 6.0 and involves only
>> it''s logfiles or kernel output.
>> During the installation CentOS was not able to get an IP address
(dhcp).
>> After booting from LVM-drive "lspci" listed the correct PCI
device:
>> 00:04.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet
>> Controller (rev 03)
>>
>> There was NO network configuration .. even for dhcp (in ifcfg-eth0).
>> After setting it manually "service network restart" hang a
while after
>> like "Determining of information for eth0 .. " and gave
"failed" back.
>> There were three dhcp-Discover requests on eth0 in dom0 but no responce
>> for requests from CentOS HVM.
>>
>> tcpdump -i eth0 -vvv -s 1500 ''((port 67 or port 68) and
(udp[8:1] =
>> 0x1))''
>>
> Ok, so the question is "why your dhcp server is not responding?"
>
> Did you also tcpdump on "peth0" interface in dom0, to make sure
the
> dhcp requests
> actually go *out* from the physical interface?Yes - I traced with tcpdump. dhcp requests or icmp don''t go out.
> Do you see the dhcp requests on the dhcp server? run tcpdump on the 
> dhcp server aswell.No.
>> I made the same test with "ubuntu 11.04 server" as HVM ..
with the same
>> "failed" message. After I have installed this ubuntu iso
image on bare
>> metal (another HP DL385g7) and didn''t run in such troubles.
The
>> installation has got an IP address (dhcp) and after boot there was also
>> an IP address for eth0.
>>
>> How can I trace the dhcp install issue? Below are some details and 
>> traces:
>>
>> HVM config file:
>>
http://www.it-infrastrukturen.com/fileadmin/linux/paste/xen-centos-issues/hvm-centos1Gbit.born2b3.net.cfg
>>
>>
>> Details about the test server / xen installation (dom0):
>>
http://www.it-infrastrukturen.com/fileadmin/linux/paste/xen-centos-issues/dom0_details.txt
>>
>>
http://www.it-infrastrukturen.com/fileadmin/linux/debian-live-xen/config-3.0.1
>>
>>
>> Trace details (for CentOS domU):
>>
http://www.it-infrastrukturen.com/fileadmin/linux/paste/xen-centos-issues/grub.conf_CentOS_kernel-debug-output-on
>>
>>
http://www.it-infrastrukturen.com/fileadmin/linux/paste/xen-centos-issues/centos-kernel-output.txt
>>
>>
http://www.it-infrastrukturen.com/fileadmin/linux/paste/xen-centos-issues/config-2.6.32-71.el6.x86_64
>>
>>
>>
>> As I don''t like to give up I have set a static IP for eth0 in
ifcfg-eth0
>> and restarted network service.
>> Now CentOS domU has got an IP address and "route" showed the
default
>> gateway however it is only possible to ping dom0 (and not default
>> gateway). Probably I am missing here something else.
>>
> Are you sure you''re using free/unused static MAC address for the
VM ?Yes. I use different MAC addresses for vif interfaces.
> And again, run tcpdump in dom0 on "peth0" interface and make sure
the
> icmp packets go *out* from dom0 to physical network.There are *no* packages (ICMP) on peth0 .. they are only on eth0
> Also run tcpdump on the router/defaultgateway. Can you see the icmp 
> packets there?No (for CentOS HVM)
>> Some details:
>>
http://www.it-infrastrukturen.com/fileadmin/linux/paste/xen-centos-issues/ip-issue-centos-hvm.txt
>>
>>
>> For tests I have used xen 4.1.2* debian live image (kernel 3.0.1 final
>> with some xen settings) booting dom0 from an USB stick (s. details
>> below).
>>
http://www.it-infrastrukturen.com/fileadmin/linux/debian-live-xen/README.xen-live
>>
-- 
ms@it-infrastrukturen.org




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

Pasi Kärkkäinen

2011-Aug-15 21:48 UTC

head link

Re: [Xen-users] Re: [Xen-devel] xen 4.1.2* dhcp issue/bug when installing/booting HVM domU domains (CentOS 6, unbuntu 11.04 server). Debian/OpenSolaris work fine.

On Mon, Aug 15, 2011 at 11:12:26PM +0200, Mark Schneider
wrote:> 
>    Tested and *nonworking* working OSes (no IP address):
>    - CentOS 6.0
> 
> 
>    Pings from *centos-hvm* to dom0 interface*no ip-traffic on peth0*
This is just like it should be. When you ping dom0 packets obviously should not
go out.
> 
>    root@xen411dom0:/ftp/HVM# tcpdump  -i eth0 ''icmp[icmptype] =
icmp-echo and
>    icmp[icmptype] != icmp-echoreply''
>    tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
>    listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
>    19:45:30.283679 IP 192.168.1.180 > 192.168.1.124: ICMP echo request,
id
>    61445, seq 23, length 64
>    19:45:31.285560 IP 192.168.1.180 > 192.168.1.124: ICMP echo request,
id
>    61445, seq 24, length 64
> 
And here on the bridge you see traffic, so that''s ok.

>    Pings from *centos-hvm* to default gateway *no ip-traffic on peth0*
> 
So here''s your problem. Your bridge in dom0 is NOT forwarding the
packets out to peth0..

>    root@xen411dom0:/ftp/HVM# tcpdump  -i eth0 ''icmp[icmptype] =
icmp-echo and
>    icmp[icmptype] != icmp-echoreply''
>    tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
>    listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
>    19:54:00.770442 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id
518,
>    seq 23, length 64
>    19:54:01.770958 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id
518,
>    seq 24, length 64
So where are these packets going to ? They''re not getting out of dom0..

Do you have a firewall rule in dom0 that drops them? 

Try these:
- In the HVM guest: run "arp -an" and check what MAC address you see
for the gateway-IP.
- In dom0: run "brctl showmacs eth0" and verify which port has the MAC
of the gateway.


-- Pasi


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

Mark Schneider

2011-Aug-15 21:55 UTC

head link

Re: [Xen-users] Re: [Xen-devel] xen 4.1.2* dhcp issue/bug when installing/booting HVM domU domains (CentOS 6, unbuntu 11.04 server). Debian/OpenSolaris work fine.

Am 15.08.2011 23:48, schrieb Pasi Kärkkäinen:> brctl showmacs eth0

-- 
IT-Infrastrukturen.ORG

ms@it-infrastrukturen.org
http://www.it-infrastrukturen.org

+++ Free infrastructure software for all. +++


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

Mark Schneider

2011-Aug-15 21:58 UTC

head link

Re: [Xen-users] Re: [Xen-devel] xen 4.1.2* dhcp issue/bug when installing/booting HVM domU domains (CentOS 6, unbuntu 11.04 server). Debian/OpenSolaris work fine.

Am 15.08.2011 23:48, schrieb Pasi Kärkkäinen:> On Mon, Aug 15, 2011 at 11:12:26PM +0200, Mark Schneider wrote:
>    
>>     Tested and *nonworking* working OSes (no IP address):
>>     - CentOS 6.0
>>
>>
>>     Pings from *centos-hvm* to dom0 interface*no ip-traffic on peth0*
>>      
> This is just like it should be. When you ping dom0 packets obviously should
not go out.
>
>    
>>     root@xen411dom0:/ftp/HVM# tcpdump  -i eth0 ''icmp[icmptype]
= icmp-echo and
>>     icmp[icmptype] != icmp-echoreply''
>>     tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
>>     listening on eth0, link-type EN10MB (Ethernet), capture size 65535
bytes
>>     19:45:30.283679 IP 192.168.1.180>  192.168.1.124: ICMP echo
request, id
>>     61445, seq 23, length 64
>>     19:45:31.285560 IP 192.168.1.180>  192.168.1.124: ICMP echo
request, id
>>     61445, seq 24, length 64
>>
>>      
> And here on the bridge you see traffic, so that''s ok.
>
>
>    
>>     Pings from *centos-hvm* to default gateway *no ip-traffic on peth0*
>>
>>      
> So here''s your problem. Your bridge in dom0 is NOT forwarding the
packets out to peth0..
>
>
>    
>>     root@xen411dom0:/ftp/HVM# tcpdump  -i eth0 ''icmp[icmptype]
= icmp-echo and
>>     icmp[icmptype] != icmp-echoreply''
>>     tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
>>     listening on eth0, link-type EN10MB (Ethernet), capture size 65535
bytes
>>     19:54:00.770442 IP 192.168.1.180>  192.168.1.1: ICMP echo
request, id 518,
>>     seq 23, length 64
>>     19:54:01.770958 IP 192.168.1.180>  192.168.1.1: ICMP echo
request, id 518,
>>     seq 24, length 64
>>      
> So where are these packets going to ? They''re not getting out of
dom0..
>
> Do you have a firewall rule in dom0 that drops them?
>
> Try these:
> - In the HVM guest: run "arp -an" and check what MAC address you
see for the gateway-IP.
> - In dom0: run "brctl showmacs eth0" and verify which port has
the MAC of the gateway.
>    [root@centoshvm ~]# arp -an
? (192.168.1.102) auf 00:1c:25:7e:fb:b7 [ether] auf eth0
? (192.168.1.124) auf b4:99:ba:c1:27:36 [ether] auf eth0


root@xen411dom0:~# brctl showmacs eth0
port no mac addr                is local?       ageing timer
   6     00:16:3e:27:17:67       no                 3.22
   3     00:16:3e:27:20:67       no                40.85
   1     00:1c:25:7e:fb:b7       no                 0.00
   1     00:1d:7e:ad:35:a8       no                12.66
   1     b4:99:ba:c1:27:36       yes                0.00
   2     fe:ff:ff:ff:ff:ff       yes                0.00
root@xen411dom0:~# arp -an
? (192.168.1.102) auf 00:1c:25:7e:fb:b7 [ether] auf eth0
? (192.168.1.180) auf 00:16:3e:27:17:67 [ether] auf eth0
? (192.168.1.1) auf 00:1d:7e:ad:35:a8 [ether] auf eth0

Thank you, Mark

-- 
ms@it-infrastrukturen.org
http://www.it-infrastrukturen.org



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

Pasi Kärkkäinen

2011-Aug-15 22:23 UTC

head link

Re: [Xen-users] Re: [Xen-devel] xen 4.1.2* dhcp issue/bug when installing/booting HVM domU domains (CentOS 6, unbuntu 11.04 server). Debian/OpenSolaris work fine.

On Mon, Aug 15, 2011 at 11:58:24PM +0200, Mark Schneider
wrote:>>    
>>>     Pings from *centos-hvm* to default gateway *no ip-traffic on
peth0*
>>>
>>>      
>> So here''s your problem. Your bridge in dom0 is NOT forwarding
the packets out to peth0..
>>
>>
>>    
>>>     root@xen411dom0:/ftp/HVM# tcpdump  -i eth0
''icmp[icmptype] = icmp-echo and
>>>     icmp[icmptype] != icmp-echoreply''
>>>     tcpdump: verbose output suppressed, use -v or -vv for full
protocol decode
>>>     listening on eth0, link-type EN10MB (Ethernet), capture size
65535 bytes
>>>     19:54:00.770442 IP 192.168.1.180>  192.168.1.1: ICMP echo
request, id 518,
>>>     seq 23, length 64
>>>     19:54:01.770958 IP 192.168.1.180>  192.168.1.1: ICMP echo
request, id 518,
>>>     seq 24, length 64
>>>      
>> So where are these packets going to ? They''re not getting out
of dom0..
>>
>> Do you have a firewall rule in dom0 that drops them?
>>
>> Try these:
>> - In the HVM guest: run "arp -an" and check what MAC address
you see for the gateway-IP.
>> - In dom0: run "brctl showmacs eth0" and verify which port
has the MAC of the gateway.
>>    
> [root@centoshvm ~]# arp -an
> ? (192.168.1.102) auf 00:1c:25:7e:fb:b7 [ether] auf eth0
> ? (192.168.1.124) auf b4:99:ba:c1:27:36 [ether] auf eth0
>
So the HVM guest has NOT received a MAC address for the gateway.. 
so ARP requests are not working from the HVM guest.

Do this:
- Shutdown the VM.
- Start the VM.
- Run tcpdump in dom0 (tcpdump -i tap<x> -nn)
- Try pinging the gateway from the HVM guest.
- Paste the whole tcpdump output here.

>
> root@xen411dom0:~# brctl showmacs eth0
> port no mac addr                is local?       ageing timer
>   6     00:16:3e:27:17:67       no                 3.22
>   3     00:16:3e:27:20:67       no                40.85
>   1     00:1c:25:7e:fb:b7       no                 0.00
>   1     00:1d:7e:ad:35:a8       no                12.66
>   1     b4:99:ba:c1:27:36       yes                0.00
>   2     fe:ff:ff:ff:ff:ff       yes                0.00
> root@xen411dom0:~# arp -an
> ? (192.168.1.102) auf 00:1c:25:7e:fb:b7 [ether] auf eth0
> ? (192.168.1.180) auf 00:16:3e:27:17:67 [ether] auf eth0
> ? (192.168.1.1) auf 00:1d:7e:ad:35:a8 [ether] auf eth0
>
Are you running some firewall (iptables or ebtables) in dom0 ? 


-- Pasi


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

Mark Schneider

2011-Aug-15 22:57 UTC

head link

Re: [Xen-users] Re: [Xen-devel] xen 4.1.2* dhcp issue/bug when installing/booting HVM domU domains (CentOS 6, unbuntu 11.04 server). Debian/OpenSolaris work fine.

Am 16.08.2011 00:23, schrieb Pasi Kärkkäinen:> On Mon, Aug 15, 2011 at 11:58:24PM +0200, Mark Schneider wrote:
>    
>>>
>>>        
>>>>      Pings from *centos-hvm* to default gateway *no ip-traffic
on peth0*
>>>>
>>>>
>>>>          
>>> So here''s your problem. Your bridge in dom0 is NOT
forwarding the packets out to peth0..
>>>
>>>
>>>
>>>        
>>>>      root@xen411dom0:/ftp/HVM# tcpdump  -i eth0
''icmp[icmptype] = icmp-echo and
>>>>      icmp[icmptype] != icmp-echoreply''
>>>>      tcpdump: verbose output suppressed, use -v or -vv for full
protocol decode
>>>>      listening on eth0, link-type EN10MB (Ethernet), capture
size 65535 bytes
>>>>      19:54:00.770442 IP 192.168.1.180>   192.168.1.1: ICMP
echo request, id 518,
>>>>      seq 23, length 64
>>>>      19:54:01.770958 IP 192.168.1.180>   192.168.1.1: ICMP
echo request, id 518,
>>>>      seq 24, length 64
>>>>
>>>>          
>>> So where are these packets going to ? They''re not getting
out of dom0..
>>>
>>> Do you have a firewall rule in dom0 that drops them?
>>>
>>> Try these:
>>> - In the HVM guest: run "arp -an" and check what MAC
address you see for the gateway-IP.
>>> - In dom0: run "brctl showmacs eth0" and verify which
port has the MAC of the gateway.
>>>
>>>        
>> [root@centoshvm ~]# arp -an
>> ? (192.168.1.102) auf 00:1c:25:7e:fb:b7 [ether] auf eth0
>> ? (192.168.1.124) auf b4:99:ba:c1:27:36 [ether] auf eth0
>>
>>      
> So the HVM guest has NOT received a MAC address for the gateway..
> so ARP requests are not working from the HVM guest.
>
> Do this:
> - Shutdown the VM.
> - Start the VM.
> - Run tcpdump in dom0 (tcpdump -i tap<x>  -nn)
> - Try pinging the gateway from the HVM guest.
> - Paste the whole tcpdump output here.
>
>
>    
>> root@xen411dom0:~# brctl showmacs eth0
>> port no mac addr                is local?       ageing timer
>>    6     00:16:3e:27:17:67       no                 3.22
>>    3     00:16:3e:27:20:67       no                40.85
>>    1     00:1c:25:7e:fb:b7       no                 0.00
>>    1     00:1d:7e:ad:35:a8       no                12.66
>>    1     b4:99:ba:c1:27:36       yes                0.00
>>    2     fe:ff:ff:ff:ff:ff       yes                0.00
>> root@xen411dom0:~# arp -an
>> ? (192.168.1.102) auf 00:1c:25:7e:fb:b7 [ether] auf eth0
>> ? (192.168.1.180) auf 00:16:3e:27:17:67 [ether] auf eth0
>> ? (192.168.1.1) auf 00:1d:7e:ad:35:a8 [ether] auf eth0
>>
>>      
> Are you running some firewall (iptables or ebtables) in dom0 ?
>    No. It is plane wheezy with 3.0.1 kernel

# ---
root@xen411dom0:~# tcpdump -i tap9.0 -nn | tee /tmp/tcpdum-tap9.0.txt
tcpdump: WARNING: tap9.0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap9.0, link-type EN10MB (Ethernet), capture size 65535 bytes
22:51:32.525644 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 1, length 64
22:51:33.526662 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 2, length 64
22:51:34.526849 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 3, length 64
22:51:35.527052 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 4, length 64
22:51:36.527114 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 5, length 64
22:51:37.527233 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 6, length 64
22:51:38.527325 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 7, length 64
22:51:39.527707 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 8, length 64
22:51:40.527521 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 9, length 64
22:51:41.527674 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 10, length 64
22:51:42.527765 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 11, length 64
22:51:43.527769 ARP, Request who-has 192.168.1.1 tell 192.168.1.180, 
length 28
22:51:43.527926 ARP, Reply 192.168.1.1 is-at 00:1d:7e:ad:35:a8, length 46
22:51:43.528599 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 12, length 64
22:51:44.529009 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 13, length 64
22:51:45.529137 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 14, length 64
22:51:46.529284 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 15, length 64
22:51:47.192618 IP 0.0.0.0 > 224.0.0.1: igmp query v2
22:51:47.192651 IP6 fe80::b699:baff:fec1:2736 > ff02::1: HBH ICMP6, 
multicast listener querymax resp delay: 1000 addr: ::, length 24
22:51:47.324329 IP6 fe80::216:3eff:fe27:1767 > ff02::1:ff27:1767: HBH 
ICMP6, multicast listener reportmax resp delay: 0 addr: 
ff02::1:ff27:1767, length 24
22:51:47.529421 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 16, length 64
22:51:47.886465 IP6 fe80::216:3eff:fe27:1767 > ff02::202: HBH ICMP6, 
multicast listener reportmax resp delay: 0 addr: ff02::202, length 24
22:51:48.529542 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 17, length 64
22:51:49.529741 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 18, length 64
22:51:50.529889 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 19, length 64
22:51:51.529929 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 20, length 64
22:51:52.530056 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 21, length 64
22:51:53.530170 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 22, length 64
22:51:54.530317 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 23, length 64
22:51:55.530413 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 24, length 64
22:51:56.530603 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 25, length 64
22:51:57.530723 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 26, length 64
22:51:58.530814 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 27, length 64
22:51:59.531236 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 28, length 64
22:52:00.531054 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 29, length 64
22:52:01.531158 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 30, length 64
22:52:02.531352 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 31, length 64
22:52:03.531452 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 32, length 64
22:52:04.531551 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 33, length 64
22:52:05.531748 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 34, length 64
22:52:06.531879 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 35, length 64
22:52:07.532014 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 36, length 64
22:52:08.532055 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 37, length 64
22:52:09.534235 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 38, length 64
22:52:10.534336 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 39, length 64
22:52:11.534439 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 40, length 64
22:52:12.534630 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 41, length 64
22:52:13.534748 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 42, length 64
22:52:14.534856 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 43, length 64
22:52:15.535128 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 44, length 64
22:52:16.535098 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 45, length 64
22:52:17.535198 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 46, length 64
22:52:18.535358 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 47, length 64
22:52:19.535564 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 48, length 64
22:52:20.535493 ARP, Request who-has 192.168.1.1 tell 192.168.1.180, 
length 28
22:52:20.535663 ARP, Reply 192.168.1.1 is-at 00:1d:7e:ad:35:a8, length 46
22:52:20.536094 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 49, length 64
22:52:21.536726 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 50, length 64
22:52:22.536845 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 51, length 64
22:52:23.536974 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 52, length 64
22:52:24.537096 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 53, length 64
22:52:25.537279 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 54, length 64
22:52:26.537372 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 55, length 64
22:52:27.537537 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 56, length 64
22:52:28.537658 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 57, length 64
22:52:29.537692 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 58, length 64
22:52:30.537889 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 59, length 64
22:52:31.538022 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 60, length 64
22:52:32.538082 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 61, length 64
22:52:33.538246 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 62, length 64
22:52:34.538365 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 63, length 64
22:52:35.538521 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 64, length 64
22:52:36.538622 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 65, length 64
22:52:37.538719 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 66, length 64
22:52:38.538942 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 67, length 64
22:52:39.538996 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 68, length 64
22:52:40.539144 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 69, length 64
22:52:41.539280 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 70, length 64
22:52:42.539463 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 71, length 64
22:52:43.539786 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 72, length 64
22:52:44.539640 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 73, length 64
22:52:45.539771 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 74, length 64
22:52:46.540000 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 75, length 64
22:52:47.540049 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 76, length 64
22:52:47.975050 IP6 fe80::216:3eff:fe27:2067 > ff02::1: ICMP6, neighbor 
advertisement, tgt is fe80::216:3eff:fe27:2067, length 32
22:52:48.540271 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 77, length 64
22:52:49.542286 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 78, length 64
22:52:50.542428 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 79, length 64
22:52:51.542559 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 80, length 64
22:52:52.542671 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 81, length 64
22:52:53.542796 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 82, length 64
22:52:54.504716 IP6 fe80::216:3eff:fe27:2067.546 > ff02::1:2.547: dhcp6 
solicit
22:52:54.542960 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 83, length 64
22:52:55.543103 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 84, length 64
22:52:56.543129 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 85, length 64
22:52:57.543313 ARP, Request who-has 192.168.1.1 tell 192.168.1.180, 
length 28
22:52:57.543462 ARP, Reply 192.168.1.1 is-at 00:1d:7e:ad:35:a8, length 46
22:52:57.543808 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 86, length 64
22:52:58.544471 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 87, length 64
22:52:59.545561 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 88, length 64
22:53:00.545808 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 89, length 64
22:53:01.545789 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 90, length 64
22:53:02.546004 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 91, length 64
22:53:03.546027 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 92, length 64
22:53:04.546249 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 93, length 64
22:53:05.546429 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 94, length 64
22:53:06.546476 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 95, length 64
22:53:07.546621 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 96, length 64
22:53:08.546739 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 97, length 64
22:53:09.546897 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 98, length 64
22:53:10.546976 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 99, length 64
22:53:11.547121 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 100, length 64
22:53:12.547152 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 101, length 64
22:53:13.547338 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 102, length 64
22:53:14.547483 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 103, length 64
22:53:15.547630 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 104, length 64
22:53:16.547774 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 105, length 64
22:53:17.547884 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 106, length 64
22:53:18.548024 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 107, length 64
22:53:19.548104 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 108, length 64
22:53:20.548338 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 109, length 64
22:53:21.548446 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 110, length 64
22:53:22.548440 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 111, length 64
22:53:23.548643 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 112, length 64
22:53:24.548881 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
56069, seq 113, length 64
22:53:52.632691 IP 0.0.0.0 > 224.0.0.1: igmp query v2
22:53:52.632726 IP6 fe80::b699:baff:fec1:2736 > ff02::1: HBH ICMP6, 
multicast listener querymax resp delay: 1000 addr: ::, length 24
22:53:52.834307 IP6 fe80::216:3eff:fe27:1767 > ff02::1:ff27:1767: HBH 
ICMP6, multicast listener reportmax resp delay: 0 addr: 
ff02::1:ff27:1767, length 24
22:53:53.480335 IP6 fe80::216:3eff:fe27:1767 > ff02::202^C131 packets 
captured
131 packets received by filter
0 packets dropped by kernel


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

Mark Schneider

2011-Aug-15 23:16 UTC

head link

Re: [Xen-users] Re: [Xen-devel] xen 4.1.2* dhcp issue/bug when installing/booting HVM domU domains (CentOS 6, unbuntu 11.04 server). Debian/OpenSolaris work fine.

Am 16.08.2011 00:57, schrieb Mark Schneider:> Am 16.08.2011 00:23, schrieb Pasi Kärkkäinen:
>> On Mon, Aug 15, 2011 at 11:58:24PM +0200, Mark Schneider wrote:
>>>>
>>>>>      Pings from *centos-hvm* to default gateway *no
ip-traffic on
>>>>> peth0*
>>>>>
>>>>>
>>>> So here''s your problem. Your bridge in dom0 is NOT
forwarding the
>>>> packets out to peth0..
>>>>
>>>>
>>>>
>>>>>      root@xen411dom0:/ftp/HVM# tcpdump  -i eth0
''icmp[icmptype] =
>>>>> icmp-echo and
>>>>>      icmp[icmptype] != icmp-echoreply''
>>>>>      tcpdump: verbose output suppressed, use -v or -vv for
full
>>>>> protocol decode
>>>>>      listening on eth0, link-type EN10MB (Ethernet),
capture size
>>>>> 65535 bytes
>>>>>      19:54:00.770442 IP 192.168.1.180>   192.168.1.1:
ICMP echo
>>>>> request, id 518,
>>>>>      seq 23, length 64
>>>>>      19:54:01.770958 IP 192.168.1.180>   192.168.1.1:
ICMP echo
>>>>> request, id 518,
>>>>>      seq 24, length 64
>>>>>
>>>> So where are these packets going to ? They''re not
getting out of
>>>> dom0..
>>>>
>>>> Do you have a firewall rule in dom0 that drops them?
>>>>
>>>> Try these:
>>>> - In the HVM guest: run "arp -an" and check what MAC
address you
>>>> see for the gateway-IP.
>>>> - In dom0: run "brctl showmacs eth0" and verify which
port has the
>>>> MAC of the gateway.
>>>>
>>> [root@centoshvm ~]# arp -an
>>> ? (192.168.1.102) auf 00:1c:25:7e:fb:b7 [ether] auf eth0
>>> ? (192.168.1.124) auf b4:99:ba:c1:27:36 [ether] auf eth0
>>>
>> So the HVM guest has NOT received a MAC address for the gateway..
>> so ARP requests are not working from the HVM guest.
>>
>> Do this:
>> - Shutdown the VM.
>> - Start the VM.
>> - Run tcpdump in dom0 (tcpdump -i tap<x>  -nn)
>> - Try pinging the gateway from the HVM guest.
>> - Paste the whole tcpdump output here.
>>
>>
>>> root@xen411dom0:~# brctl showmacs eth0
>>> port no mac addr                is local?       ageing timer
>>>    6     00:16:3e:27:17:67       no                 3.22
>>>    3     00:16:3e:27:20:67       no                40.85
>>>    1     00:1c:25:7e:fb:b7       no                 0.00
>>>    1     00:1d:7e:ad:35:a8       no                12.66
>>>    1     b4:99:ba:c1:27:36       yes                0.00
>>>    2     fe:ff:ff:ff:ff:ff       yes                0.00
>>> root@xen411dom0:~# arp -an
>>> ? (192.168.1.102) auf 00:1c:25:7e:fb:b7 [ether] auf eth0
>>> ? (192.168.1.180) auf 00:16:3e:27:17:67 [ether] auf eth0
>>> ? (192.168.1.1) auf 00:1d:7e:ad:35:a8 [ether] auf eth0
>>>
>> Are you running some firewall (iptables or ebtables) in dom0 ?
> No. It is plane wheezy with 3.0.1 kernel
>
> # ---
> root@xen411dom0:~# tcpdump -i tap9.0 -nn | tee /tmp/tcpdum-tap9.0.txt
> tcpdump: WARNING: tap9.0: no IPv4 address assigned
> tcpdump: verbose output suppressed, use -v or -vv for full protocol 
> decode
> listening on tap9.0, link-type EN10MB (Ethernet), capture size 65535 
> bytes
> 22:51:32.525644 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 1, length 64
> 22:51:33.526662 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 2, length 64
> 22:51:34.526849 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 3, length 64
> 22:51:35.527052 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 4, length 64
> 22:51:36.527114 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 5, length 64
> 22:51:37.527233 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 6, length 64
> 22:51:38.527325 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 7, length 64
> 22:51:39.527707 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 8, length 64
> 22:51:40.527521 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 9, length 64
> 22:51:41.527674 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 10, length 64
> 22:51:42.527765 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 11, length 64
> 22:51:43.527769 ARP, Request who-has 192.168.1.1 tell 192.168.1.180, 
> length 28
> 22:51:43.527926 ARP, Reply 192.168.1.1 is-at 00:1d:7e:ad:35:a8, length 46
> 22:51:43.528599 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 12, length 64
> 22:51:44.529009 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 13, length 64
> 22:51:45.529137 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 14, length 64
> 22:51:46.529284 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 15, length 64
> 22:51:47.192618 IP 0.0.0.0 > 224.0.0.1: igmp query v2
> 22:51:47.192651 IP6 fe80::b699:baff:fec1:2736 > ff02::1: HBH ICMP6, 
> multicast listener querymax resp delay: 1000 addr: ::, length 24
> 22:51:47.324329 IP6 fe80::216:3eff:fe27:1767 > ff02::1:ff27:1767: HBH 
> ICMP6, multicast listener reportmax resp delay: 0 addr: 
> ff02::1:ff27:1767, length 24
> 22:51:47.529421 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 16, length 64
> 22:51:47.886465 IP6 fe80::216:3eff:fe27:1767 > ff02::202: HBH ICMP6, 
> multicast listener reportmax resp delay: 0 addr: ff02::202, length 24
> 22:51:48.529542 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 17, length 64
> 22:51:49.529741 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 18, length 64
> 22:51:50.529889 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 19, length 64
> 22:51:51.529929 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 20, length 64
> 22:51:52.530056 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 21, length 64
> 22:51:53.530170 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 22, length 64
> 22:51:54.530317 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 23, length 64
> 22:51:55.530413 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 24, length 64
> 22:51:56.530603 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 25, length 64
> 22:51:57.530723 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 26, length 64
> 22:51:58.530814 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 27, length 64
> 22:51:59.531236 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 28, length 64
> 22:52:00.531054 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 29, length 64
> 22:52:01.531158 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 30, length 64
> 22:52:02.531352 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 31, length 64
> 22:52:03.531452 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 32, length 64
> 22:52:04.531551 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 33, length 64
> 22:52:05.531748 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 34, length 64
> 22:52:06.531879 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 35, length 64
> 22:52:07.532014 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 36, length 64
> 22:52:08.532055 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 37, length 64
> 22:52:09.534235 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 38, length 64
> 22:52:10.534336 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 39, length 64
> 22:52:11.534439 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 40, length 64
> 22:52:12.534630 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 41, length 64
> 22:52:13.534748 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 42, length 64
> 22:52:14.534856 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 43, length 64
> 22:52:15.535128 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 44, length 64
> 22:52:16.535098 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 45, length 64
> 22:52:17.535198 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 46, length 64
> 22:52:18.535358 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 47, length 64
> 22:52:19.535564 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 48, length 64
> 22:52:20.535493 ARP, Request who-has 192.168.1.1 tell 192.168.1.180, 
> length 28
> 22:52:20.535663 ARP, Reply 192.168.1.1 is-at 00:1d:7e:ad:35:a8, length 46
> 22:52:20.536094 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 49, length 64
> 22:52:21.536726 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 50, length 64
> 22:52:22.536845 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 51, length 64
> 22:52:23.536974 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 52, length 64
> 22:52:24.537096 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 53, length 64
> 22:52:25.537279 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 54, length 64
> 22:52:26.537372 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 55, length 64
> 22:52:27.537537 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 56, length 64
> 22:52:28.537658 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 57, length 64
> 22:52:29.537692 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 58, length 64
> 22:52:30.537889 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 59, length 64
> 22:52:31.538022 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 60, length 64
> 22:52:32.538082 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 61, length 64
> 22:52:33.538246 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 62, length 64
> 22:52:34.538365 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 63, length 64
> 22:52:35.538521 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 64, length 64
> 22:52:36.538622 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 65, length 64
> 22:52:37.538719 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 66, length 64
> 22:52:38.538942 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 67, length 64
> 22:52:39.538996 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 68, length 64
> 22:52:40.539144 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 69, length 64
> 22:52:41.539280 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 70, length 64
> 22:52:42.539463 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 71, length 64
> 22:52:43.539786 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 72, length 64
> 22:52:44.539640 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 73, length 64
> 22:52:45.539771 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 74, length 64
> 22:52:46.540000 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 75, length 64
> 22:52:47.540049 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 76, length 64
> 22:52:47.975050 IP6 fe80::216:3eff:fe27:2067 > ff02::1: ICMP6, 
> neighbor advertisement, tgt is fe80::216:3eff:fe27:2067, length 32
> 22:52:48.540271 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 77, length 64
> 22:52:49.542286 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 78, length 64
> 22:52:50.542428 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 79, length 64
> 22:52:51.542559 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 80, length 64
> 22:52:52.542671 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 81, length 64
> 22:52:53.542796 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 82, length 64
> 22:52:54.504716 IP6 fe80::216:3eff:fe27:2067.546 > ff02::1:2.547: 
> dhcp6 solicit
> 22:52:54.542960 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 83, length 64
> 22:52:55.543103 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 84, length 64
> 22:52:56.543129 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 85, length 64
> 22:52:57.543313 ARP, Request who-has 192.168.1.1 tell 192.168.1.180, 
> length 28
> 22:52:57.543462 ARP, Reply 192.168.1.1 is-at 00:1d:7e:ad:35:a8, length 46
> 22:52:57.543808 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 86, length 64
> 22:52:58.544471 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 87, length 64
> 22:52:59.545561 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 88, length 64
> 22:53:00.545808 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 89, length 64
> 22:53:01.545789 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 90, length 64
> 22:53:02.546004 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 91, length 64
> 22:53:03.546027 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 92, length 64
> 22:53:04.546249 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 93, length 64
> 22:53:05.546429 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 94, length 64
> 22:53:06.546476 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 95, length 64
> 22:53:07.546621 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 96, length 64
> 22:53:08.546739 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 97, length 64
> 22:53:09.546897 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 98, length 64
> 22:53:10.546976 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 99, length 64
> 22:53:11.547121 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 100, length 64
> 22:53:12.547152 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 101, length 64
> 22:53:13.547338 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 102, length 64
> 22:53:14.547483 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 103, length 64
> 22:53:15.547630 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 104, length 64
> 22:53:16.547774 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 105, length 64
> 22:53:17.547884 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 106, length 64
> 22:53:18.548024 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 107, length 64
> 22:53:19.548104 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 108, length 64
> 22:53:20.548338 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 109, length 64
> 22:53:21.548446 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 110, length 64
> 22:53:22.548440 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 111, length 64
> 22:53:23.548643 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 112, length 64
> 22:53:24.548881 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
> 56069, seq 113, length 64
> 22:53:52.632691 IP 0.0.0.0 > 224.0.0.1: igmp query v2
> 22:53:52.632726 IP6 fe80::b699:baff:fec1:2736 > ff02::1: HBH ICMP6, 
> multicast listener querymax resp delay: 1000 addr: ::, length 24
> 22:53:52.834307 IP6 fe80::216:3eff:fe27:1767 > ff02::1:ff27:1767: HBH 
> ICMP6, multicast listener reportmax resp delay: 0 addr: 
> ff02::1:ff27:1767, length 24
> 22:53:53.480335 IP6 fe80::216:3eff:fe27:1767 > ff02::202^C131 packets 
> captured
> 131 packets received by filter
> 0 packets dropped by kernel
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
Trace inside HVM (s. default gateway: 192.168.1.1 is-at 00:1d:7e:ad:35:a8)
# ---------------------------
[root@centoshvm ~]# tcpdump -i eth0 -nn | tee /tmp/tcpdum-eth0.txt
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
01:05:31.996278 IP 192.168.1.180.22 > 192.168.1.124.40173: Flags [P.], 
seq 1128465923:1128466115, ack 1021543041, win 135, options [nop,nop,TS 
val 1036128 ecr 3459996], length 192
01:05:31.998526 IP 192.168.1.124.40173 > 192.168.1.180.22: Flags [.], 
ack 192, win 176, options [nop,nop,TS val 3460006 ecr 1036128], length 0
01:05:55.401107 ARP, Request who-has 192.168.1.1 tell 192.168.1.180, 
length 28
01:05:55.402608 ARP, Reply 192.168.1.1 is-at 00:1d:7e:ad:35:a8, length 46
01:05:55.402681 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 1, length 64
01:05:56.399192 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 2, length 64
01:05:57.399180 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 3, length 64
01:05:58.399177 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 4, length 64
01:05:59.399187 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 5, length 64
01:06:00.399183 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 6, length 64
01:06:01.399140 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 7, length 64
01:06:02.399181 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 8, length 64
01:06:03.399132 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 9, length 64
01:06:04.399138 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 10, length 64
01:06:05.399133 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 11, length 64
01:06:06.400184 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 12, length 64
01:06:07.400143 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 13, length 64
01:06:08.400129 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 14, length 64
01:06:09.400141 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 15, length 64
01:06:10.400133 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 16, length 64
01:06:11.400134 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 17, length 64
01:06:12.400135 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 18, length 64
01:06:13.400188 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 19, length 64
01:06:14.400178 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 20, length 64
01:06:15.400186 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 21, length 64
01:06:16.400187 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 22, length 64
01:06:17.400142 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 23, length 64
01:06:18.400129 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 24, length 64
01:06:19.400140 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 25, length 64
01:06:20.400143 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 26, length 64
01:06:21.400181 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 27, length 64
01:06:22.400174 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 28, length 64
01:06:23.400138 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 29, length 64
01:06:24.062276 IP 0.0.0.0 > 224.0.0.1: igmp query v2
01:06:24.062366 IP6 fe80::b699:baff:fec1:2736 > ff02::1: HBH ICMP6, 
multicast listener querymax resp delay: 1000 addr: ::, length 24
01:06:24.400180 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 30, length 64
01:06:24.952108 IP6 fe80::216:3eff:fe27:1767 > ff02::1:ff27:1767: HBH 
ICMP6, multicast listener reportmax resp delay: 0 addr: 
ff02::1:ff27:1767, length 24
01:06:24.970041 IP6 fe80::216:3eff:fe27:1767 > ff02::202: HBH ICMP6, 
multicast listener reportmax resp delay: 0 addr: ff02::202, length 24
01:06:25.400173 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 31, length 64
01:06:26.400141 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 32, length 64
01:06:27.400146 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 33, length 64
01:06:28.400171 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 34, length 64
01:06:28.402776 IP 192.168.1.180.22 > 192.168.1.124.40173: Flags [.], 
seq 192:1640, ack 1, win 135, options [nop,nop,TS val 1092534 ecr 
3460006], length 1448
01:06:28.403767 IP 192.168.1.180.22 > 192.168.1.124.40173: Flags [.], 
seq 1640:3088, ack 1, win 135, options [nop,nop,TS val 1092535 ecr 
3460006], length 1448
01:06:28.404352 IP 192.168.1.180.22 > 192.168.1.124.40173: Flags [P.], 
seq 3088:4336, ack 1, win 135, options [nop,nop,TS val 1092536 ecr 
3460006], length 1248
01:06:28.406695 IP 192.168.1.124.40173 > 192.168.1.180.22: Flags [.], 
ack 1640, win 198, options [nop,nop,TS val 3474109 ecr 1092534], length 0
01:06:28.406806 IP 192.168.1.180.22 > 192.168.1.124.40173: Flags [P.], 
seq 4336:4416, ack 1, win 135, options [nop,nop,TS val 1092538 ecr 
3474109], length 80
01:06:28.408178 IP 192.168.1.124.40173 > 192.168.1.180.22: Flags [.], 
ack 3088, win 221, options [nop,nop,TS val 3474109 ecr 1092535], length 0
01:06:28.408252 IP 192.168.1.124.40173 > 192.168.1.180.22: Flags [.], 
ack 4336, win 244, options [nop,nop,TS val 3474110 ecr 1092536], length 0
01:06:28.408271 IP 192.168.1.124.40173 > 192.168.1.180.22: Flags [.], 
ack 4416, win 244, options [nop,nop,TS val 3474110 ecr 1092538], length 0
01:06:29.400175 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 35, length 64
01:06:30.400194 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 36, length 64
01:06:31.400167 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 37, length 64
01:06:32.400135 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 38, length 64
01:06:33.400132 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 39, length 64
01:06:33.404728 ARP, Request who-has 192.168.1.180 tell 192.168.1.124, 
length 46
01:06:33.404815 ARP, Reply 192.168.1.180 is-at 00:16:3e:27:17:67, length 28
01:06:34.400187 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 40, length 64
01:06:35.400186 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 41, length 64
01:06:36.400185 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 42, length 64
01:06:37.400135 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 43, length 64
01:06:38.400166 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 44, length 64
01:06:39.400161 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 45, length 64
01:06:40.400131 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 46, length 64
01:06:41.400142 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 47, length 64
01:06:42.400151 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 48, length 64
01:06:43.400019 ARP, Request who-has 192.168.1.1 tell 192.168.1.180, 
length 28
01:06:43.400772 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
5894, seq 49, length 64
01:06:43.401287 ARP, Reply 192.168.1.1 is-at 00:1d:7e:ad:35:a8, length 46

-- 
IT-Infrastrukturen.ORG

ms@it-infrastrukturen.org
http://www.it-infrastrukturen.org

+++ Free infrastructure software for all. +++


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

Pasi Kärkkäinen

2011-Aug-16 07:43 UTC

head link

Re: [Xen-users] Re: [Xen-devel] xen 4.1.2* dhcp issue/bug when installing/booting HVM domU domains (CentOS 6, unbuntu 11.04 server). Debian/OpenSolaris work fine.

On Tue, Aug 16, 2011 at 01:16:18AM +0200, Mark Schneider
wrote:> Am 16.08.2011 00:57, schrieb Mark Schneider:
>> Am 16.08.2011 00:23, schrieb Pasi Kärkkäinen:
>>> On Mon, Aug 15, 2011 at 11:58:24PM +0200, Mark Schneider wrote:
>>>>>
>>>>>>      Pings from *centos-hvm* to default gateway *no
ip-traffic
>>>>>> on peth0*
>>>>>>
>>>>>>
>>>>> So here''s your problem. Your bridge in dom0 is NOT
forwarding the
>>>>> packets out to peth0..
>>>>>
>>>>>
>>>>>
>>>>>>      root@xen411dom0:/ftp/HVM# tcpdump  -i eth0
''icmp[icmptype]
>>>>>> = icmp-echo and
>>>>>>      icmp[icmptype] != icmp-echoreply''
>>>>>>      tcpdump: verbose output suppressed, use -v or -vv
for full
>>>>>> protocol decode
>>>>>>      listening on eth0, link-type EN10MB (Ethernet),
capture
>>>>>> size 65535 bytes
>>>>>>      19:54:00.770442 IP 192.168.1.180>  
192.168.1.1: ICMP echo
>>>>>> request, id 518,
>>>>>>      seq 23, length 64
>>>>>>      19:54:01.770958 IP 192.168.1.180>  
192.168.1.1: ICMP echo
>>>>>> request, id 518,
>>>>>>      seq 24, length 64
>>>>>>
>>>>> So where are these packets going to ? They''re not
getting out of
>>>>> dom0..
>>>>>
>>>>> Do you have a firewall rule in dom0 that drops them?
>>>>>
>>>>> Try these:
>>>>> - In the HVM guest: run "arp -an" and check what
MAC address you
>>>>> see for the gateway-IP.
>>>>> - In dom0: run "brctl showmacs eth0" and verify
which port has
>>>>> the MAC of the gateway.
>>>>>
>>>> [root@centoshvm ~]# arp -an
>>>> ? (192.168.1.102) auf 00:1c:25:7e:fb:b7 [ether] auf eth0
>>>> ? (192.168.1.124) auf b4:99:ba:c1:27:36 [ether] auf eth0
>>>>
>>> So the HVM guest has NOT received a MAC address for the gateway..
>>> so ARP requests are not working from the HVM guest.
>>>
>>> Do this:
>>> - Shutdown the VM.
>>> - Start the VM.
>>> - Run tcpdump in dom0 (tcpdump -i tap<x>  -nn)
>>> - Try pinging the gateway from the HVM guest.
>>> - Paste the whole tcpdump output here.
>>>
>>>
>>>> root@xen411dom0:~# brctl showmacs eth0
>>>> port no mac addr                is local?       ageing timer
>>>>    6     00:16:3e:27:17:67       no                 3.22
>>>>    3     00:16:3e:27:20:67       no                40.85
>>>>    1     00:1c:25:7e:fb:b7       no                 0.00
>>>>    1     00:1d:7e:ad:35:a8       no                12.66
>>>>    1     b4:99:ba:c1:27:36       yes                0.00
>>>>    2     fe:ff:ff:ff:ff:ff       yes                0.00
>>>> root@xen411dom0:~# arp -an
>>>> ? (192.168.1.102) auf 00:1c:25:7e:fb:b7 [ether] auf eth0
>>>> ? (192.168.1.180) auf 00:16:3e:27:17:67 [ether] auf eth0
>>>> ? (192.168.1.1) auf 00:1d:7e:ad:35:a8 [ether] auf eth0
>>>>
>>> Are you running some firewall (iptables or ebtables) in dom0 ?
>> No. It is plane wheezy with 3.0.1 kernel
>>
and "iptables -L -n -v" does not list any rules? 
>
> Trace inside HVM (s. default gateway: 192.168.1.1 is-at 00:1d:7e:ad:35:a8)
> # ---------------------------
> [root@centoshvm ~]# tcpdump -i eth0 -nn | tee /tmp/tcpdum-eth0.txt
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
> 01:05:31.996278 IP 192.168.1.180.22 > 192.168.1.124.40173: Flags [P.],  
> seq 1128465923:1128466115, ack 1021543041, win 135, options [nop,nop,TS  
> val 1036128 ecr 3459996], length 192
> 01:05:31.998526 IP 192.168.1.124.40173 > 192.168.1.180.22: Flags [.],  
> ack 192, win 176, options [nop,nop,TS val 3460006 ecr 1036128], length 0
> 01:05:55.401107 ARP, Request who-has 192.168.1.1 tell 192.168.1.180,  
> length 28
> 01:05:55.402608 ARP, Reply 192.168.1.1 is-at 00:1d:7e:ad:35:a8, length 46
> 01:05:55.402681 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id  
> 5894, seq 1, length 64
> 01:05:56.399192 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id  
>
So the HVM domU gets the correct MAC of the gateway,
and starts sending packets to it.

The next step would be to dump on eth0 on dom0.. do you see the same packets
there?

At the same time also dump on peth0, do the packets go out there to the physical
network?


-- Pasi


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

Mark Schneider

2011-Aug-16 19:05 UTC

head link

Re: [Xen-users] Re: [Xen-devel] xen 4.1.2* dhcp issue/bug when installing/booting HVM domU domains (CentOS 6, unbuntu 11.04 server). Debian/OpenSolaris work fine.

Am 16.08.2011 09:43, schrieb Pasi Kärkkäinen:> On Tue, Aug 16, 2011 at 01:16:18AM +0200, Mark Schneider wrote:
>    
>> Am 16.08.2011 00:57, schrieb Mark Schneider:
>>      
>>> Am 16.08.2011 00:23, schrieb Pasi Kärkkäinen:
>>>        
>>>> On Mon, Aug 15, 2011 at 11:58:24PM +0200, Mark Schneider wrote:
>>>>          
>>>>>>              
>>>>>>>       Pings from *centos-hvm* to default gateway
*no ip-traffic
>>>>>>> on peth0*
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>> So here''s your problem. Your bridge in dom0 is
NOT forwarding the
>>>>>> packets out to peth0..
>>>>>>
>>>>>>
>>>>>>
>>>>>>              
>>>>>>>       root@xen411dom0:/ftp/HVM# tcpdump  -i eth0
''icmp[icmptype]
>>>>>>> = icmp-echo and
>>>>>>>       icmp[icmptype] != icmp-echoreply''
>>>>>>>       tcpdump: verbose output suppressed, use -v or
-vv for full
>>>>>>> protocol decode
>>>>>>>       listening on eth0, link-type EN10MB
(Ethernet), capture
>>>>>>> size 65535 bytes
>>>>>>>       19:54:00.770442 IP 192.168.1.180>   
192.168.1.1: ICMP echo
>>>>>>> request, id 518,
>>>>>>>       seq 23, length 64
>>>>>>>       19:54:01.770958 IP 192.168.1.180>   
192.168.1.1: ICMP echo
>>>>>>> request, id 518,
>>>>>>>       seq 24, length 64
>>>>>>>
>>>>>>>                
>>>>>> So where are these packets going to ? They''re
not getting out of
>>>>>> dom0..
>>>>>>
>>>>>> Do you have a firewall rule in dom0 that drops them?
>>>>>>
>>>>>> Try these:
>>>>>> - In the HVM guest: run "arp -an" and check
what MAC address you
>>>>>> see for the gateway-IP.
>>>>>> - In dom0: run "brctl showmacs eth0" and
verify which port has
>>>>>> the MAC of the gateway.
>>>>>>
>>>>>>              
>>>>> [root@centoshvm ~]# arp -an
>>>>> ? (192.168.1.102) auf 00:1c:25:7e:fb:b7 [ether] auf eth0
>>>>> ? (192.168.1.124) auf b4:99:ba:c1:27:36 [ether] auf eth0
>>>>>
>>>>>            
>>>> So the HVM guest has NOT received a MAC address for the
gateway..
>>>> so ARP requests are not working from the HVM guest.
>>>>
>>>> Do this:
>>>> - Shutdown the VM.
>>>> - Start the VM.
>>>> - Run tcpdump in dom0 (tcpdump -i tap<x>   -nn)
>>>> - Try pinging the gateway from the HVM guest.
>>>> - Paste the whole tcpdump output here.
>>>>
>>>>
>>>>          
>>>>> root@xen411dom0:~# brctl showmacs eth0
>>>>> port no mac addr                is local?       ageing
timer
>>>>>     6     00:16:3e:27:17:67       no                 3.22
>>>>>     3     00:16:3e:27:20:67       no                40.85
>>>>>     1     00:1c:25:7e:fb:b7       no                 0.00
>>>>>     1     00:1d:7e:ad:35:a8       no                12.66
>>>>>     1     b4:99:ba:c1:27:36       yes                0.00
>>>>>     2     fe:ff:ff:ff:ff:ff       yes                0.00
>>>>> root@xen411dom0:~# arp -an
>>>>> ? (192.168.1.102) auf 00:1c:25:7e:fb:b7 [ether] auf eth0
>>>>> ? (192.168.1.180) auf 00:16:3e:27:17:67 [ether] auf eth0
>>>>> ? (192.168.1.1) auf 00:1d:7e:ad:35:a8 [ether] auf eth0
>>>>>
>>>>>            
>>>> Are you running some firewall (iptables or ebtables) in dom0 ?
>>>>          
>>> No. It is plane wheezy with 3.0.1 kernel
>>>
>>>        
> and "iptables -L -n -v" does not list any rules?
>    
root@xen411dom0:~# iptables -L -n -v
Chain INPUT (policy ACCEPT 232 packets, 25984 bytes)
  pkts bytes target     prot opt in     out     source               
destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source               
destination
     0     0 ACCEPT     all  --  *      *       0.0.0.0/0            
0.0.0.0/0            PHYSDEV match --physdev-in peth0

Chain OUTPUT (policy ACCEPT 184 packets, 24528 bytes)
  pkts bytes target     prot opt in     out     source               
destination
root@xen411dom0:~#
>> Trace inside HVM (s. default gateway: 192.168.1.1 is-at
00:1d:7e:ad:35:a8)
>> # ---------------------------
>> [root@centoshvm ~]# tcpdump -i eth0 -nn | tee /tmp/tcpdum-eth0.txt
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
>> listening on eth0, link-type EN10MB (Ethernet), capture size 65535
bytes
>> 01:05:31.996278 IP 192.168.1.180.22>  192.168.1.124.40173: Flags
[P.],
>> seq 1128465923:1128466115, ack 1021543041, win 135, options [nop,nop,TS
>> val 1036128 ecr 3459996], length 192
>> 01:05:31.998526 IP 192.168.1.124.40173>  192.168.1.180.22: Flags
[.],
>> ack 192, win 176, options [nop,nop,TS val 3460006 ecr 1036128], length
0
>> 01:05:55.401107 ARP, Request who-has 192.168.1.1 tell 192.168.1.180,
>> length 28
>> 01:05:55.402608 ARP, Reply 192.168.1.1 is-at 00:1d:7e:ad:35:a8, length
46
>> 01:05:55.402681 IP 192.168.1.180>  192.168.1.1: ICMP echo request,
id
>> 5894, seq 1, length 64
>> 01:05:56.399192 IP 192.168.1.180>  192.168.1.1: ICMP echo request,
id
>>      
> So the HVM domU gets the correct MAC of the gateway,
> and starts sending packets to it.
>
> The next step would be to dump on eth0 on dom0.. do you see the same
packets there?
>
> At the same time also dump on peth0, do the packets go out there to the
physical network?
>    
# Requests and reply on peth0 are there:
18:06:00.324825 ARP, Request who-has 192.168.1.1 tell 192.168.1.180, 
length 28
18:06:00.325012 ARP, Reply 192.168.1.1 is-at 00:1d:7e:ad:35:a8, length 46

# Requests and reply on eth0 are *also* there:
18:06:00.324825 ARP, Request who-has 192.168.1.1 tell 192.168.1.180, 
length 28
18:06:00.325012 ARP, Reply 192.168.1.1 is-at 00:1d:7e:ad:35:a8, length 46

# There are ICMP requests on eth0 but look like that there are *not 
forwarded* to peth0.
18:06:00.334350 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
55045, seq 1, length 64
18:06:01.324098 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id 
55045, seq 2, length 64

Any idea why? I have attached both tpcdumps.

I use the same dom0 domain for other HVMs like squeeze, wheezy or 
OpenSolaris and the work as expected.

Thank you / regards, Mark

--
ms@it-infrastrukturen.org





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

Pasi Kärkkäinen

2011-Aug-16 19:30 UTC

head link

Re: [Xen-users] Re: [Xen-devel] xen 4.1.2* dhcp issue/bug when installing/booting HVM domU domains (CentOS 6, unbuntu 11.04 server). Debian/OpenSolaris work fine.

On Tue, Aug 16, 2011 at 09:05:13PM +0200, Mark Schneider
wrote:>>>>>>>>                
>>>>>>> So here''s your problem. Your bridge in
dom0 is NOT forwarding the
>>>>>>> packets out to peth0..
>>>>>>>
>>>>>>>
>>>>>>> So where are these packets going to ?
They''re not getting out of
>>>>>>> dom0..
>>>>>>>
>>>>>>> Do you have a firewall rule in dom0 that drops
them?
>>>>>>>
>>>>        
>> and "iptables -L -n -v" does not list any rules?
>>    
>
> root@xen411dom0:~# iptables -L -n -v
> Chain INPUT (policy ACCEPT 232 packets, 25984 bytes)
>  pkts bytes target     prot opt in     out     source                
> destination
>
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>  pkts bytes target     prot opt in     out     source                
> destination
>     0     0 ACCEPT     all  --  *      *       0.0.0.0/0             
> 0.0.0.0/0            PHYSDEV match --physdev-in peth0
>
So you DO have a firewall in place!

As a default ALL packets are DROPped!
And you''re only allowing packets to other direction? 

> Chain OUTPUT (policy ACCEPT 184 packets, 24528 bytes)
>  pkts bytes target     prot opt in     out     source                
> destination
> root@xen411dom0:~#
>
>>>      
>> So the HVM domU gets the correct MAC of the gateway,
>> and starts sending packets to it.
>>
>> The next step would be to dump on eth0 on dom0.. do you see the same
packets there?
>>
>> At the same time also dump on peth0, do the packets go out there to the
physical network?
>>    
>
> # Requests and reply on peth0 are there:
> 18:06:00.324825 ARP, Request who-has 192.168.1.1 tell 192.168.1.180,  
> length 28
> 18:06:00.325012 ARP, Reply 192.168.1.1 is-at 00:1d:7e:ad:35:a8, length 46
>
> # Requests and reply on eth0 are *also* there:
> 18:06:00.324825 ARP, Request who-has 192.168.1.1 tell 192.168.1.180,  
> length 28
> 18:06:00.325012 ARP, Reply 192.168.1.1 is-at 00:1d:7e:ad:35:a8, length 46
>
> # There are ICMP requests on eth0 but look like that there are *not  
> forwarded* to peth0.
> 18:06:00.334350 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id  
> 55045, seq 1, length 64
> 18:06:01.324098 IP 192.168.1.180 > 192.168.1.1: ICMP echo request, id  
> 55045, seq 2, length 64
>
So the problem is in dom0 Linux kernel configuration.

> Any idea why? I have attached both tpcdumps.
>
Because of the firewall rule? 

-- Pasi


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

Mark Schneider

2011-Aug-17 21:58 UTC

head link

Re: [Xen-users] Re: [Xen-devel] xen 4.1.2* dhcp issue/bug when installing/booting HVM domU domains (CentOS 6, unbuntu 11.04 server). Debian/OpenSolaris work fine.

Am 16.08.2011 21:30, schrieb Pasi Kärkkäinen:> On Tue, Aug 16, 2011 at 09:05:13PM +0200, Mark Schneider wrote:
>    
>>>>>>>>>
>>>>>>>>>                    
>>>>>>>> So here''s your problem. Your bridge in
dom0 is NOT forwarding the
>>>>>>>> packets out to peth0..
>>>>>>>>
>>>>>>>>
>>>>>>>> So where are these packets going to ?
They''re not getting out of
>>>>>>>> dom0..
>>>>>>>>
>>>>>>>> Do you have a firewall rule in dom0 that drops
them?
>>>>>>>>
>>>>>>>>                  
>>> and "iptables -L -n -v" does not list any rules?
>>>
>>>        
>> root@xen411dom0:~# iptables -L -n -v
>> Chain INPUT (policy ACCEPT 232 packets, 25984 bytes)
>>   pkts bytes target     prot opt in     out     source
>> destination
>>
>> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>>   pkts bytes target     prot opt in     out     source
>> destination
>>      0     0 ACCEPT     all  --  *      *       0.0.0.0/0
>> 0.0.0.0/0            PHYSDEV match --physdev-in peth0
>>
>>      
> So you DO have a firewall in place!
>
> As a default ALL packets are DROPped!
> And you''re only allowing packets to other direction?
>    
What I am wondering about is that if I boot or install debian wheezy and 
squeezy or OpenSolaris iptables on dom0 is getting automatically such rules:
# ---
root@xen411dom0:/etc/xen# xm list
Name                                        ID   Mem VCPUs      State   
Time(s)
Domain-0                                     0  1536     2     r-----   
1835.8
opensolarishvm.born2b3.net                   9  4096     2     -b----    
156.0
squeezehvm.born2b3.net                       7  8192     4     
-b----     20.1
wheezyhvm.born2b3.net                        1  8192     8     
-b----     32.0
root@xen411dom0:/etc/xen#
root@xen411dom0:/etc/xen#
root@xen411dom0:/etc/xen# iptables -L -v -n
Chain INPUT (policy ACCEPT 5366 packets, 14M bytes)
  pkts bytes target     prot opt in     out     source               
destination

Chain FORWARD (policy DROP 8 packets, 2624 bytes)
  pkts bytes target     prot opt in     out     source               
destination
    59 59899 ACCEPT     all  --  *      *       0.0.0.0/0            
0.0.0.0/0            PHYSDEV match --physdev-out vif9.0 --physdev-is-bridged
   239 24809 ACCEPT     all  --  *      *       0.0.0.0/0            
0.0.0.0/0            PHYSDEV match --physdev-in vif9.0 --physdev-is-bridged
    51 13943 ACCEPT     all  --  *      *       0.0.0.0/0            
0.0.0.0/0            PHYSDEV match --physdev-out vif7.0 --physdev-is-bridged
    13  2944 ACCEPT     all  --  *      *       0.0.0.0/0            
0.0.0.0/0            PHYSDEV match --physdev-in vif7.0 --physdev-is-bridged
    59 17120 ACCEPT     all  --  *      *       0.0.0.0/0            
0.0.0.0/0            PHYSDEV match --physdev-out vif1.0 --physdev-is-bridged
    14  1564 ACCEPT     all  --  *      *       0.0.0.0/0            
0.0.0.0/0            PHYSDEV match --physdev-in vif1.0 --physdev-is-bridged
     0     0 ACCEPT     all  --  *      *       0.0.0.0/0            
0.0.0.0/0            PHYSDEV match --physdev-in peth0

Chain OUTPUT (policy ACCEPT 5264 packets, 14M bytes)
  pkts bytes target     prot opt in     out     source               
destination
# ---


>>> So the HVM domU gets the correct MAC of the gateway,
>>> and starts sending packets to it.
>>>
>>> The next step would be to dump on eth0 on dom0.. do you see the
same packets there?
>>>
>>> At the same time also dump on peth0, do the packets go out there to
the physical network?
>>>
>>>        
>> # Requests and reply on peth0 are there:
>> 18:06:00.324825 ARP, Request who-has 192.168.1.1 tell 192.168.1.180,
>> length 28
>> 18:06:00.325012 ARP, Reply 192.168.1.1 is-at 00:1d:7e:ad:35:a8, length
46
>>
>> # Requests and reply on eth0 are *also* there:
>> 18:06:00.324825 ARP, Request who-has 192.168.1.1 tell 192.168.1.180,
>> length 28
>> 18:06:00.325012 ARP, Reply 192.168.1.1 is-at 00:1d:7e:ad:35:a8, length
46
>>
>> # There are ICMP requests on eth0 but look like that there are *not
>> forwarded* to peth0.
>> 18:06:00.334350 IP 192.168.1.180>  192.168.1.1: ICMP echo request,
id
>> 55045, seq 1, length 64
>> 18:06:01.324098 IP 192.168.1.180>  192.168.1.1: ICMP echo request,
id
>> 55045, seq 2, length 64
>>      
> So the problem is in dom0 Linux kernel configuration.
>    As the current kernel configuration of dom0 (s. below) works (with 
automatic setting of iptable rules) for debian / opensolaris why
doesn''t
it work in the same manner for CentOS 6.0 or NetBSD 5.1? (install and boot)
http://www.it-infrastrukturen.com/fileadmin/linux/debian-live-xen/config-3.0.1

What is different for CentOS or NetBSD images? .. PVM-HVM network 
drivers support in kernel of dom0?
>> Any idea why? I have attached both tpcdumps.
>>      
> Because of the firewall rule?
>
> -- Pasi
>    Thanks a lot Pasi.

Regards, Mark

-- 
ms@it-infrastrukturen.org



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

Pasi Kärkkäinen

2011-Aug-17 22:03 UTC

head link

Re: [Xen-users] Re: [Xen-devel] xen 4.1.2* dhcp issue/bug when installing/booting HVM domU domains (CentOS 6, unbuntu 11.04 server). Debian/OpenSolaris work fine.

On Wed, Aug 17, 2011 at 11:58:05PM +0200, Mark Schneider
wrote:>>>>        
>>> root@xen411dom0:~# iptables -L -n -v
>>> Chain INPUT (policy ACCEPT 232 packets, 25984 bytes)
>>>   pkts bytes target     prot opt in     out     source
>>> destination
>>>
>>> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>>>   pkts bytes target     prot opt in     out     source
>>> destination
>>>      0     0 ACCEPT     all  --  *      *       0.0.0.0/0
>>> 0.0.0.0/0            PHYSDEV match --physdev-in peth0
>>>
>>>      
>> So you DO have a firewall in place!
>>
>> As a default ALL packets are DROPped!
>> And you''re only allowing packets to other direction?
>>    
>
>>>      
>> So the problem is in dom0 Linux kernel configuration.
>>    
> As the current kernel configuration of dom0 (s. below) works (with  
> automatic setting of iptable rules) for debian / opensolaris why
doesn''t
> it work in the same manner for CentOS 6.0 or NetBSD 5.1? (install and 
> boot)
>
http://www.it-infrastrukturen.com/fileadmin/linux/debian-live-xen/config-3.0.1
>
> What is different for CentOS or NetBSD images? .. PVM-HVM network  
> drivers support in kernel of dom0?
>
The traffic from PVHVM drivers comes from vif-interface, not from tap-interface!
tap-interface is used by the qemu-dm emulated nics, while vif-interface is used
by pv-drivers.

>>> Any idea why? I have attached both tpcdumps.
>>>      
>> Because of the firewall rule?
>>
>> -- Pasi
>>    
> Thanks a lot Pasi.
>

-- Pasi


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

Seemingly Similar Threads

Search for more possibly parallel threads

Xen users - Aug 2011 - Re: [Xen-devel] xen 4.1.2* dhcp issue/bug when installing/booting HVM domU domains (CentOS 6, unbuntu 11.04 server). Debian/OpenSolaris work fine.

[Xen-users] Re: [Xen-devel] xen 4.1.2* dhcp issue/bug when installing/booting HVM domU domains (CentOS 6, unbuntu 11.04 server). Debian/OpenSolaris work fine.

Re: [Xen-users] Re: [Xen-devel] xen 4.1.2* dhcp issue/bug when installing/booting HVM domU domains (CentOS 6, unbuntu 11.04 server). Debian/OpenSolaris work fine.

Re: [Xen-users] Re: [Xen-devel] xen 4.1.2* dhcp issue/bug when installing/booting HVM domU domains (CentOS 6, unbuntu 11.04 server). Debian/OpenSolaris work fine.

Re: [Xen-users] Re: [Xen-devel] xen 4.1.2* dhcp issue/bug when installing/booting HVM domU domains (CentOS 6, unbuntu 11.04 server). Debian/OpenSolaris work fine.

Re: [Xen-users] Re: [Xen-devel] xen 4.1.2* dhcp issue/bug when installing/booting HVM domU domains (CentOS 6, unbuntu 11.04 server). Debian/OpenSolaris work fine.

Re: [Xen-users] Re: [Xen-devel] xen 4.1.2* dhcp issue/bug when installing/booting HVM domU domains (CentOS 6, unbuntu 11.04 server). Debian/OpenSolaris work fine.

Re: [Xen-users] Re: [Xen-devel] xen 4.1.2* dhcp issue/bug when installing/booting HVM domU domains (CentOS 6, unbuntu 11.04 server). Debian/OpenSolaris work fine.

Re: [Xen-users] Re: [Xen-devel] xen 4.1.2* dhcp issue/bug when installing/booting HVM domU domains (CentOS 6, unbuntu 11.04 server). Debian/OpenSolaris work fine.

Re: [Xen-users] Re: [Xen-devel] xen 4.1.2* dhcp issue/bug when installing/booting HVM domU domains (CentOS 6, unbuntu 11.04 server). Debian/OpenSolaris work fine.

Re: [Xen-users] Re: [Xen-devel] xen 4.1.2* dhcp issue/bug when installing/booting HVM domU domains (CentOS 6, unbuntu 11.04 server). Debian/OpenSolaris work fine.

Re: [Xen-users] Re: [Xen-devel] xen 4.1.2* dhcp issue/bug when installing/booting HVM domU domains (CentOS 6, unbuntu 11.04 server). Debian/OpenSolaris work fine.

Re: [Xen-users] Re: [Xen-devel] xen 4.1.2* dhcp issue/bug when installing/booting HVM domU domains (CentOS 6, unbuntu 11.04 server). Debian/OpenSolaris work fine.

Seemingly Similar Threads