Connecting FOG to Virtual Machine
-
@Quazz I booted to iPXE.pxe but i’m sure what i’m doing with this CL to boot to FOG. I’ve tried ‘autoboot’ but i got the output “Nothing to boot: No such file or directory”
-
@agray Where did you change these things?
-
@Quazz I mounted the .iso to my VM and booted to it.
-
@agray You need to serve the ipxe.pxe file that’s on the FOG server, since it seems to be the DHCP server.
That being said
I can boot VirtualBox 5.2 VMs to IPXE on undionly.kpxe as well as ipxe.pxe just fine.
Do you have the VirtualBox extension pack installed?
-
@Quazz said in Connecting FOG to Virtual Machine:
Do you have the VirtualBox extension pack installed?
Yes, but my VirtualBox is 6.0. Would that make a difference?
-
Is there a way to use FOG off a usb to capture. that may be a work around i can use
-
@Quazz @Sebastian-Roth Would my physical machine being on my domain be causing this issue?
-
@agray What exactly do you mean by “Domain”? As in Windows Domain? This has nothing to do with PXE boot. Or as in network domain like VLAN or subnet? That might play a hole.
I think the best would be you capture the network traffic on your host machine using wireshark, save as PCAP file, upload to a file share and post a download link here.
Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)
Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG
-
@Sebastian-Roth Here is the .pcap file of my VM attempting to PXE boot from the host point of view: https://drive.google.com/file/d/1zbHmSCoOC2tzi8xp5EVnj6KrhQwvSOcU/view?usp=sharing
After attempting to PXE boot with host off AD Domain. I’m getting a nicer looking wireshark output but still no dice on the PXE boot: https://drive.google.com/file/d/11GiICfArOKqcFUWdF6hQHV51r8oHTebV/view?usp=sharing
-
@agray I’m assuming that if it’s on the domain that there already is a DHCP server on the network and that it is conflicting with the FOG one. Haven’t taken a look at the PCAP (don’t have time), though
-
@Quazz Our domain is strictly static and FOG is isolated completely off it. A rough topology of our FOG network is on the second page of this thread
-
@agray Yes, and around that same area it is mentioned that there is a DHCP server on the router?
-
@Quazz That would be the FOG Server.
-
@agray Just looked at the PCAP.
Your router is also dishing out IPs at 192.168.1.1 which is causing the conflict as suspected.
You can check it out by installing wireshark and typign in
bootpas filterIf you can’t turn off or modify the router DHCP, you will need dnsmasq proxyDHCP on the FOG server.
https://wiki.fogproject.org/wiki/index.php?title=ProxyDHCP_with_dnsmasq
-
@Quazz said in Connecting FOG to Virtual Machine:
our router is also dishing out IPs
I turned off the DHCP server option on the router and it still didn’t fix the problem, I took a pcap if you’d like it.
It seems odd to me that my router would only be messing up the VM though. Never had an issue with physical machines and the router. -
@agray OK I also looked at the second pcap the first one didn’t have anything useful that I could see.
In the second pcap you have 2 dhcp servers responding to the target computer. The first one is 192.168.1.1 and the second is 192.168.1.90. .90 appears to be a fog server since its handing out the right next server and boot file name. The issue is that it appears to be configured as a full dhcp server since its also handing out an IP address which is in conflict with what your 192.168.1.1 dhcp server is doing.
Looking at the pcap more the .90 dhcp is winning the election process because its responding with a ACK packet.
I want you to follow this tutorial when creating your PCAP so we only get the info we need and not extra internal messages: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
-
@agray I guess the question needs to be asked are you running the dhcp server on the fog server for a reason in addition to the dhcp server on your router?
Which dhcp server do you want to run? I understand the goal is to pxe boot your clients but there is a number of ways to go about it, depending on what your main goal is.
-
@george1421 said in Connecting FOG to Virtual Machine:
unning the dhcp server on the fog server for a reason in addition to the dhcp server on your router
I was unaware the FOG machine had that capabilities honestly. With that now being known, I feel it would be easier for FOG to handle everything since it was overwriting the router anyway.
I did disable the DHCP server capabilities on the router to hand it off to FOG.Let me restart everything to make sure that the server is not handing out IPs anymore and I’ll post another pcap file here if the PXE boot fails again: https://drive.google.com/file/d/1R7fLhBw7umZ6A_gEZ5rvneKQX0Y0Mw_6/view?usp=sharing
-
@agray I would say that looks like a normal pcap except I don’t see it transferring the file. If you look at the pcap we see a Discover, Offer, Request, and ACK. Then the client request the file size of undionly.kpxe and then requests the file… from there it stops. Then after 30 seconds or so it sends out a discover again and the fog server responds with an offer but then it cycles between discover and offer.
So my question is this: Does this happen with the VM only, where a physical computer boots normally?
I might understand what is happening but not the why just yet. I did notice that the mac address of the device in your picture doesn’t match the mac address of the pxe booting device in the pcap [08:00:27:8a:86:44].
-
@george1421 said in Connecting FOG to Virtual Machine:
Does this happen with the VM only, where a physical computer boots normally?
If I’m understanding correctly, my physical machine boot perfectly into the FOG GUI it gives me after PXE.
@george1421 said in Connecting FOG to Virtual Machine:
the mac address of the device in your picture doesn’t match the mac address of the pxe
It changed because i had to rebuild the VM. I was originally logged into the Network admin account and, since I had to get off the domain, I exported the VM and brought it back up in the local admin account.
