Network connectivity to Fog seems extremely slow from Hyper-V
-
We’ve been working with a physical host of Fog for a few years now that has been working great. No issues at all speed wise or imaging wise. However, our team decided to virtualize the server on Hyper-V so we could get rid of the old desktop that we’re currently using.
We got Fog set up with the newest version, but we just can’t seem to get it working right. When computers first PXE boot, the tftp icon comes up and spins for a bit (never even seen it before on the old server). Then once bzimage begins to load, it takes about 30 seconds to reach 100%, same with init.xz.
The switch port for the Hyper-V host is configured exactly the same way as the port for the physical host, so I’m doubting this being the issue.
-
Not to ignore you, but when I came in this morning, me and my boss had a conversation. He was messing around with another VM that was also having speed issues. He turned off VMQ under the Hardware Acceleration for the VM’s NIC on Hyper-V. His file transfer speed issue immediately went away. Naturally, I tried this for the FOG VM. When I booted up a machine, PXE boot ran as expected. I never saw the TFTP spinning, and both bzimage and init loaded instantly. However, I turned VMQ back on and tried again and the speed issue was still gone, so I don’t know if this was a problematic setting or not.
If the speed issue comes back, I will go ahead and do the tcpdump, unless you’d like me to do it now anyways just for sake of gaining info. FOG is running on the latest Ubuntu Server OS.
-
@zpoling As there is not much IO data transfer, CPU or RAM usage involved in loading iPXE binary and kernel. I think we can rule out those three for now. That leaves us with network I suppose. Do you know how to capture and analyze a network packet dump with wireshark/tcpdump? Probably best if you can capture a dump on the FOG server like this:
tcpdump -o /tmp/slow.pcap host x.x.x.x(where x.x.x.x is the IP of the client host you are going to use for testing)
Leave that command sitting there and boot up that one client specified on the tcpdump command. When kernel is about half way through stop tcpdump (Ctrl+c). That should be more than enough data to get an idea if network is an issue or not.Upload that
slow.pcapfile to your dropbox and post a link here or send me a private chat message if you don’t want to share this with all the people here. Although there is nothing confidential in the packet dump I assure you. The filter used with tcpdump only saves the packet information going between FOG server and this one particular client and it does only do a normal PXE boot. So nothing to hide there really!By the way, which kind of OS you are running FOG on?
-
Not to ignore you, but when I came in this morning, me and my boss had a conversation. He was messing around with another VM that was also having speed issues. He turned off VMQ under the Hardware Acceleration for the VM’s NIC on Hyper-V. His file transfer speed issue immediately went away. Naturally, I tried this for the FOG VM. When I booted up a machine, PXE boot ran as expected. I never saw the TFTP spinning, and both bzimage and init loaded instantly. However, I turned VMQ back on and tried again and the speed issue was still gone, so I don’t know if this was a problematic setting or not.
If the speed issue comes back, I will go ahead and do the tcpdump, unless you’d like me to do it now anyways just for sake of gaining info. FOG is running on the latest Ubuntu Server OS.