So yer right.
Mounting the shared folder is easy enough, but NFS wants a block device with a file system, which a directory is not.
boo.
Back to an attached .vhd I go.
So yer right.
Mounting the shared folder is easy enough, but NFS wants a block device with a file system, which a directory is not.
boo.
Back to an attached .vhd I go.
Aside from doing it manually, it would be nice if you could download into a local repository/cache then locally swap by selecting internet delivered or locally cached; instead of relying on the internet all the time.
A Gen1 machine using Legacy Adapter maxes out at 100 Mb.
A Gen2 machine using the default `network adapter’ maxes out at the hosts’ max.
It sounds like you are creating and capturing on the same physical box to the same single physical drive.
You want to to create your VMs on one drive, while capturing to a different drive.
Also, you really want to use an SSD for your VM drive.
Immediately before capturing CentOS 7.x I do the following.
# Direct next Kernel recompilation to include AHCI drivers & be HW generic
sed -i 's|#add_drivers+="|add_drivers+="ahci|g' /etc/dracut.conf
sed -i 's|#hostonly="yes|hostonly="no|g' /etc/dracut.conf
# Clean & Update the OS (includes Kernel recompilation)
yum clean all
yum makecache
yum update -y
# Shutdown
shutdown now
GIT 4274 has everything back in running order.
@Tom-Elliott unidonly.pxe can’t dhcp, ipxe.pxe hangs at iPXE initialising devices.
Okay, setting to UEFI boot and snp.efi . It works.
Re-instating bg.png. It still works.
Sigh… so UEFI it will be. Time to upgrade the DHCP server.
btw, iPXE is 2d42d
So far today, working with all new VMs again, things are looking good.
I made one change to the mastering process, to use Disk Management (diskmgmt.msc) within Windows to shrink the OS partition (to just 5GB free space) before sysprep and shutdown. It’s capturing partitions properly with fixed 1:2:4 so far.
Captured images are deploying properly to HDDs both larger and smaller than the original 64GB.
Good news everyone! Now it’s my turn to be called an idiot… maybe
When FOG came in as our deployment solution I also quickly ramped up through server revisions (core and gui) to our current 2012 R2u1 and Hyper-V. My initial tests with Fog 0.29 with whichever version of Hyper-V it was at the time, showed that I couldn’t PXE boot properly unless I disconnected the Ethernet adapter from the Virtual Switch, leaving the Legacy Adapter connected alone. One or the other could be connected, but not both at the same time.
Annoying, but the workaround … worked; albeit at 100Mb.
I couldn’t sleep tonight (yep, it’s 2am) so I tried something other than Quick or Full Reg; I tried a Quick Image on the Hyper-V VM. This option didn’t exist on FOG way back in 0.29 or so. I expected Quick Image to fail with what appeared to be a controller /sda no hard drive and unable to register error that appeared when attempting Quick or Full Registration. This time though, I got an adapter error.
How can this be? I can PXE boot. The Legacy adapter is obviously working.
I double checked the VM. Yep, Legacy is connected, and the ‘Ethernet’ (synthetic) is disconnected.
Hmm … so I reconnected the VM’s main ‘Ethernet’ adapter to the same virtual switch as the Legacy adapter, so both were connected at once and tried again.
The bloody thing works.
I’m glad it works but riddle me this batman. Why does 3.18.5 work with either both connected or just the Legacy connected? … while 4.1.4 requires that both be connected?
Just so ya know, I’ve successfully used FOG 1.3.0 RC16 (svn5983, kernel 4.8.1) to deploy and capture Gen1 (Legacy) and Gen2 (UEFI) virtual machines using undionly.kpxe and ipxe.efi respectively on a new Windows Server 2016 Standard with Hyper-V installed.
Lenovo is shipping me a 4X90E51405 for testing. I hope to be back into testing it soon.
I pulled version 4.1.4 of bzImage and bzImage32 from another server.
Without replacing the init’s, “Resizing Filesystem” now completes in about a minute.
No. Nothing changed on the laptop.
To get past the inits in UEFI network boot I had to use the Lenovo Mini-Ethernet Extension Adapter ( p/n: sc10a39882aa, fru: 04x6435 ) that I just acquired.
To get past the inits in Legacy network booting I can use the Lenovo ThinkPad USB 3.0 Ethernet Adapter ( p/n: SC10H30171/RTL8153 FRU: 03X6903 ) or the Lenovo Mini-Ethernet Extension Adapter ( p/n: sc10a39882aa, fru: 04x6435 ) that I just acquired.
All tests were conducted with BIOS 1.17 and fog server configuration (1.4.4 / 4.12.3).
I can now confirm that the Lenovo Mini-Ethernet Extension Adapter (p/n: sc10a39882bb, fru: 04x6435) also works in both UEFI and Legacy network boot.
Selecting the image proper, then from that image’s definition page selecting delete, then selecting to delete the image files as well, the image files are deleted, but the image definition remains.
Ironically I then go to the list all images, select the multiple images I just not quite deleted, to delete the leftover image definitions.
To quote the Professor, good news everyone!
The problem is no longer a problem as of RC22.
Thank you again for all of your hard work.
Aha, that’s why I didn’t find that post in a search. Can’t keyword search attached pictures.
Changing mine to
FOG_URL_AVAILABLE_TIMEOUT = 3000
… fixed it for me. Thank you.
Figured out why I missed it again. It is another example of the perils of using pictures instead of text and of quoting text inaccurately.
Searching for either ‘FOG_VIEW_DEFAULT_SCREEN’ or ‘FOG View Settings’ doesn’t find it, but using the incorrect ‘FOG View Setting’ (missing the s) does find it.