FOG installed on small VM. Possible to drag and drop images when needed for deployments?
-
Server
- FOG Version: 1.5.0
- OS: Kubuntu 17.04
Client
- Service Version:
- OS:
Description
I am new to FOG, and am using it to handle our Windows 10 deployments. All of our machines were until recently Windows 7, so we handled everything with Symantec Ghost. Since this is a school system and each computer lab basically gets its own individualized image, we have a lot of images and need a lot of storage space. We handled this with Ghost by running Ghost Server on a central laptop. Then, we could store images on a removable USB hard drive and could drag and drop them to the main laptop hard drive as needed. That way, we could run our deployments from the main hard drive and weren’t handicapped by the slower USB 2.0 external hard drive.
I have had good success with FOG so far. I installed it as a trial on a Hyper-V VM running Kubuntu. Since I did not realize this would become our go-to solution at the time, I did not allocate enough storage space on the virtual hard drive. Now, I am quickly running out of space. I purchased an external USB hard drive, and planned on storing images there. The problem I’m running into is that this is an older server, with only USB 2.0 ports. When I deploy images from this external drive, it crawls compared to the speed of the previous VHD hard drive.
Is there any way to set FOG up like I did with the Symantec Ghost server, where I could drag and drop images to the main hard drive when needed, then move them back to the external drive after deployment for long term storage?
Thanks for any help and advice!
-
@birvin My advice to you is just rebuild the fog server with enough space - it’s not too tough to migrate from old to new, here’s instructions on how: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG Don’t shy away from the right choice. I’d even ask for bigger drives for this older server too while you’re at it - older SAS disks can be bought new at incredibly low prices - it’s worth the investment.
-
Thanks, Wayne. Looks like we will be rebuilding it.
-
I would also offer the suggestion that you separate the /images folder onto a separate virtual disk. You Could do this without rebuilding. I’ve used USB disks on ‘toaster’ that are mounted as /images as well. In either case, this allows use to expand the /images folder w/o messing with the rest of the install.
Wayne is an expert, so maybe my approach is more work. I’ve backed into this problem over and again, as image space has grown (mostly from uploads, in my case), but we were able to mount the old volume as /oldimages, mount the new empty volume as /images, copy image, then unmount the /oldimages volume. If I recall, it was only a matter of mess with fstab in my case.
Just a thought.
Jim
-
@jim-graczyk said in FOG installed on small VM. Possible to drag and drop images when needed for deployments?:
I would also offer the suggestion that you separate the /images folder onto a separate virtual disk.
I would also recommend this. The issue I’ve seen is filling up /images with images will take down the OS since /images is part of the root file system. Its roughly equivalent to filling up the
drive of a windows computer. You typically don’t place uncontrolled growth data on your OS disk in windows, the same applies to linux.I don’t personally like the idea of shuttling in and out images as needed. But if one had some just a little bash shell scripting skills it could be done. You might think about it as a poor man’s hierarchical storage solution. You would keep active images on high speed disk and then shuttle the image to lower speed (possibly usb attached) storage.
In regards to moving the images off the root partition. I did create a tutorial on how to do this with centos, similar concept can be done with ubuntu. https://forums.fogproject.org/topic/6642/moving-fog-s-images-files-off-the-root-partition
-
@jim-graczyk said in FOG installed on small VM. Possible to drag and drop images when needed for deployments?:
Wayne is an expert, so maybe my approach is more work.
My suggestions take into consideration the present skill level of the person doing the operation. Adding a virtual disk would certainly work.
