On Aug 16, 2012, at 3:54 PM, Stefan Hajnoczi wrote: > On Thu, Aug 16, 2012 at 1:25 PM, Andrew Holway <a.holway@xxxxxxxxxxxx> wrote: >> I have a kvm vm that I am attempting to boot from pxe. The dhcp works perfectly and I can see the VM in the pxe server arp. but the tftp just times out. I don't see any tftp traffic on either the physical host or on the pie server. I am using a bridged interface. I have tried using several virtual nic drivers, several different mac addresses and several different ips. on the physical host I can get the pxelinux.0 file from the pxe server via tftp and can clearly see that traffic with tcpdump. >> >> Ive tried using various virtual interfaces. >> >> I can pxe boot my physical hosts with no problems. >> >> I can tftp fine from the physical host and see the traffic with ethdump > > Have you run tcpdump on the tap interface? (This is different from > running tcpdump on host eth0 because it is earlier in the network path > and happens before the software bridge.) Yes. I can just see DHCP traffic. > > What do iptables -L -n and ebtables -L say? > [root@node002 ~]# iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:67 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:67 Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- 0.0.0.0/0 192.168.122.0/24 state RELATED,ESTABLISHED ACCEPT all -- 192.168.122.0/24 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable Chain OUTPUT (policy ACCEPT) target prot opt source destination [root@node002 ~]# ebtables -L Bridge table: filter Bridge chain: INPUT, entries: 0, policy: ACCEPT Bridge chain: FORWARD, entries: 0, policy: ACCEPT Bridge chain: OUTPUT, entries: 0, policy: ACCEPT [root@node002 ~]# tcpdump -i vnet0 udp tcpdump: WARNING: vnet0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vnet0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:08:08.849344 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:00:00:0d (oui Ethernet), length 387 17:08:08.849413 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:00:00:0d (oui Ethernet), length 387 17:08:08.849661 IP master.cm.cluster.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 360 17:08:09.812645 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:00:00:0d (oui Ethernet), length 387 17:08:09.812709 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:00:00:0d (oui Ethernet), length 387 17:08:09.812903 IP master.cm.cluster.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 360 17:08:11.789993 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:00:00:0d (oui Ethernet), length 399 17:08:11.790107 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:00:00:0d (oui Ethernet), length 399 17:08:11.790294 IP master.cm.cluster.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 360 And then…….silence! > Stefan -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
