After trying half a dozen different pxe boot options I settled on gPXE up because it at least provides an interactive shell form which I can manually issue dhcp/http/tftp/etc requests to troubleshoot this problem.
Note, this all works booting form a disk partition. I just want to be able to NFS boot for ease of development. Although, it's approaching the point of diminishing returns.
The dom0 is an Ubuntu 9.04 dom0 2.6.32x pvops xen 4.0.1-rc3-pre. Configured with a single bridge:
#> brctl show bridge name bridge id STP enabled interfaces
eth0 8000.0026552c70c0 no peth0 tap-vif-dpm vif-dpm
The domU, has
kernel = '/usr/lib/xen/boot/hvmloader'
builder = 'hvm' boot = 'n'
device_model = 'qemu-dm' # no change hap = 0
vif = [ 'type=ioemu, mac=00:16:3e:00:22:01, vifname=vif-dpm' ] memory = 3072
I have a sniffer (wireshark) on dom0 and my dhcp server.
I see the dhcp req and resp on dom0 and the dhcp server, and domU, ....at least at first.
Whatever I configure to happen after that fails because the domU stops seeing packets. The dom0 sniffer confirms they are coming in, but they never get to domU.
If I run a couple of interactive gPXE commands like "dhcp net0", it'll work a couple of times, then quit.
If I let it run through the actual boot seq, it times out receiving the kernel via http.
I've tried tftp, http, pxegrub, syslinux, gPXE (half a dozen build flavors and options) and the result is the same: domU stops listing to packets.
The vif interface shows dropped packets:
vif-dpm Link encap:Ethernet HWaddr fe:ff:ff:ff:ff:ff inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:4477 overruns:0 carrier:0 collisions:0 txqueuelen:32
Here are the routing tables, with some logging added, but I don't get any logged matched packets.
Chain INPUT (policy ACCEPT 39108 packets, 5166K bytes) pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 27812 packets, 74M bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED PHYSDEV match --physdev-out vif-dpm
0 0 ACCEPT all -- any any anywhere anywhere PHYSDEV match --physdev-in vif-dpm 0 0 LOG all -- any any anywhere anywhere state RELATED,ESTABLISHED PHYSDEV match --physdev-out vif-dpm LOG level debug prefix `*f:FORWARD:1:ACCEPT:'
0 0 LOG udp -- any any anywhere anywhere PHYSDEV match --physdev-in vif-dpm udp spt:bootpc dpt:bootps LOG level debug prefix `*f:FORWARD:3:ACCEPT:' 0 0 LOG all -- any any anywhere anywhere state RELATED,ESTABLISHED PHYSDEV match --physdev-out vif-dpm LOG level debug prefix `*f:FORWARD:5:ACCEPT:'
0 0 LOG all -- any any kaan-22-dpm.lsi.com anywhere PHYSDEV match --physdev-in vif-dpm LOG level debug prefix `*f:FORWARD:7:ACCEPT:'
Chain OUTPUT (policy ACCEPT 28929 packets, 16M bytes) pkts bytes target prot opt in out source destination
I'm out of ideas. I posted on xen-users, first, but this appears to be a sufficiently rare use case that no one has experience with it.
I'd appreciate any ideas, thoughts, criticisms, etc.
Thanks in advance.
-Bruce
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|