I have recently tried to deploy a VM on a kvm OpenSUSE host. I am trying to use iPXE boot as this is inside the company that I work with, and the windows images deployed through ipxe are already licensed. Problem is, whenever I try to boot I only get a message like
TFTP Download: boot\x64\pxeboot.n12
.
TFTP Download: boot\x64\pxeboot.n12
…
Failed to restart TFTP.
TFTP download failed. Could not boot image: Error 0x7f8d8101 (http://ipxe.org/7f8d8101)
No more network devices
It does find the server, it does resolve the name, however it doesn’t seem to actually boot the image.
I have tried the same, on another kvm host that is in the same vlan, same switch, however, that one works (that host is CentOS 7 though). It boots the image right away and was able to deploy the guest.
Now I don’t have a whole lot of experience with iPXE, and I don’t have access to the WDS server so I am limited with what I can do. However if the CentOS machine was able to do it(same hw configuration) I am thinking this is related to the OpenSuse machine.
Not sure where to begin though, as it clearly is able to ping the WDS server and communicate, just not able to boot the image. I tried different emulated NICs all with the same result.
Please let me know what additional information I can provide. Any idea is welcome.
Early suspicion from your description without verifying your current details is that you have the personal firewall enabled on your Host and don’t have the TFTP port (or service) open. Remember, the firewall on the Host also blocks traffic to your Guests.
@tsu2, I just tried it with firewall off. Unfortunately, I get the same behavior. The working CentOS host has firewall enabled also but it doesn’t seem to be affected.
I thought maybe apparmor is to blame, but it wasn’t enabled.
Any logs I need to collect? Does virt-manager keep any network logs for the guest?
Ok, snooped around with wireshark, and I can see the read request for the file pxeboot.n12. The response received from the server is “Illegal TFTP Operation, Message: Access violation.”
Not sure if my host is doing something wrong when making the request, or if for some reason, there’s an access problem with the network. Both the CentOS host and this host are on the same vlan and same switch.
Curios thing is, I installed virtualbox to see if it could pxe boot. It works like a charm using the same bridge device.
My next suggestion if it isn’t a firewall is based more or less on what you discovered… a configuration issue.
The TFTP Server configuration should be checked for any kind of network or authentication restriction and the PXE configuration should be checked to see if there its offering any authentication to the TFTP server.
There isn’t any kind of authentication set. Basically one can connect any machine/vm to any switch and boot pxe. Authentication is done after boot is done, and it is based on domain username and password(it asks for it).
I am not sure what part of the configuration I can mess with. DHCP returns correct information. I don’t see any issue in the config.
I don’t know that any authentication would be necessarily obvious, like username/password authentication but there might be IP address filtering.
You should also inspect how/where your images are stored and served because it appears from your original post to be your point of failure… Is the image also served by TFTP, or by some other method like NFS? Is a new and separate network connection created to download the image or is the original connection re-used?
I’d also suggest you take a look at the virtual network settings your non-working Host is using compared to the virtual networks used by successful PXE clients… eg.
I assume that all are bridging networks, not NAT alrhough NAT <might> also work (depends)?
Try using a virtual network using the same address space as the others.
Inspect the physical network connections (maybe even try swapping the patch cable with a known good), bad cables can cause a variety of surprising network problems.
You didn’t describe in detail exactly what name resolution worked, could it be possible that your configs use a mixture of IP addresses and names which could result in IP addresses working but names unresolved?
Generally speaking, always remember that Guests won’t automatically be able to resolve any names related to the Host without the Host registering those names in an exterior service like a Domain DNS or WINS.
If you can’t figure this out, you might need to post the configs I suggested earlier… If you feel necessary, the content can be “sanitized” by doing things like modify the first octet of any IP addresses to change the private network, names can be replaced with something generic.
Now, except the STP and the “BRIDGE_PORTS” I don’t see any difference. I tried turning stp on on the suse box, but when I restart the network, it fails to see the bridge at all. As soon as I change the BRIDGE_STP back to off, all works. Except the pxe that is :P.
I was saying previously, if I bring up a VM on virtualbox, and pxe boot on the suse host, all is good, booting works fine. So I’m not sure it is the brdige at fault.
Anyway, here’s the output when attempting to boot on the suse host.
The VM is connected directly to the bridge, no NAT. Same configuration on the working box. DHCP working on both, because I can see it configuring the device properly when I run dhcp from ipxe.
It’s the PXE and TFTP settings (primarily the latter), to understand why from your original description the client is possibly able to start booting but fails at the point the image is supposed to be downloaded.
My suggestions to consider the virtual network configurations are because it’s possible although unusual to filter and if you were to configure your non-working Guest to use the same virtual network range as a working virtual network on another host, then it’s one step to at least make your Guests look the same to the TFTP server.