Fog 1.20 as 0.32

[Wayne Workman]

I couldn’t imagine imaging with quick image… I would rather not work like a dog as I once did with Norton Ghost.

As @george1421 said, you need to try out the features of fog - You’re seriously missing out.

I can image 500 computers in one day with the features FOG provides. And I’m only one man, with only two feet… and I don’t even need to leave my desk to do it.

I know FOG Trunk (1.3.0 beta) has quick image, not sure about 1.2.0… I’ve never actually spent any time using 1.2.0. Quick Image will do what you’re asking. But I’d urge you to rethink how you’re doing things. The way you think you want is not better.

[Tom Elliott]

@Wayne-Workman Current trunk quick image is better only because it allows the user to select what image they want. However, all versions of fog that had quick image (and forward) have quick image. In older versions, you would enter init and enter the fog credentials to approve it. In 1.x.x and forward, you don’t need two reboots to get to imaging, so in a small way it is better than it was in prior versions.

[mitzayapa]

Quick image sounds great, nevertheless ive tried a trunk version (i think it was 5552) in production ; one day gave me a an error when uploading an image and all went downhill from that.No more deploying or capturing , nothing worked after that.I need a stable edition.How do i enable quick image in 1.20?
Thank you.

[george1421]

@mitzayapa First I have to say, if you have a problem with release of a trunk version you should post it here. The debug cycle is very short with the fog project. Your issue could have been resolved since there are typically updates daily. The only way we can get to a stable very faster is to have people help with the debugging phase, then everyone wins.

As Tom noted below the all versions of the 1.x.x support quick image, so your 1.2.0 stable release supports it. What 1.2.0 doesn’t support will is uefi and gpt disk. If you need those and are unable to use the trunk build then you will have to wait until 1.3.0 is officially released.

[mitzayapa]

i dont need neighter uefi or gpt , so 1.20 will fit for my needs;now how do i enable “quick image” into my 1.20 install?I´ve seen the CAPONE plugin but i really don´t get how to make it work.(i couldnt find much documentacion about it); As my first post i need that each client that logs into network to be able to select and deploy itself without registration (as trunk/even with the user/password i dont mind).

[george1421]

@mitzayapa Its been too long since I ran the 1.2.0 stable build, but when you pxe boot the client computer, quick image should be one of the options. There is nothing to enable as long as you have captured images in your inventory. If you don’t see it, I will spin up a 1.2.0 install to confirm.

[mitzayapa]

Theres no quick image for non registered clients , thats the main issue.I need a host bypass method like in 0.32.

[george1421]

OK let me build a new fog 1.2 server and see what we have to work with.

[Tom Elliott]

Would you be willing to upgrade to trunk?

[george1421]

I checked and while the 1.2.0 stable release does have quick image it is only for registered hosts. The 1.2.0 stable version does not have the flexibility in managing the ipxe menu as the current pre1.3.0 release has so it will be a bit more difficult to accomplish.

I was able to “tweak” the ipxe boot menu in 1.2.0 to display the quick image option for unregistred systems, but I don’t know if that will break something else during image deployment because I had to bend the rules a bit for it to display. The other issue with running a “tweaked” version of the boot menu is there is no support from the dev team for this so the OP is on his own if it works or breaks something else.

In the end the OP would be better of living with short term instability in the pre 1.3.0 trunk release than “tweaking” the boot menu code. BUT, if the OP wants what the code that I updated I’ll post it here with no guaranty that it will work as intended.

[mitzayapa]

I guess i’ll stick with the 0.32 till the next stable version releases , the old one works just fine.I really apreciate the support given.

Ps: what can i make to speed up my deployment speed (more ram ? raid 0 ? 2 nics?)

[george1421]

@mitzayapa said:

Ps: what can i make to speed up my deployment speed (more ram ? raid 0 ? 2 nics?)

That is kind of hard to say, since I don’t know your setup or your environment bottlenecks. What is your transfer rate between the server to the client during depolyment (sorry its been many years since I used 0.3x I don’t remember what is avaialble).

Dual or bonded nics will not help if you have only 2 actors in the conversation (i.e. server and 1 target computer) since the bonded nics do not multiplex the data across all links in the bond (actually called a LAG or LAGG). Once a link is selected the conversation between the server and the target will continue to use the selected link during the entire conversation.
If you think about your network as a road way, you have a set speed on the road way. Adding more lanes (nics) only allows you to carry more cars (data) but at the same roadway speed.

The other thing I’ve seen is a slow disk subsystem on the FOG server impact overall speed of the imaging. This is only a guess, but if you are using 0.3.x of FOG that means your server is probably over 5 years old and probably using SCSI u160 or u320 disks. These subsystems had transfer rates in the 40-60MB/s range (about half of GbE ethernet). So even if you have a fast ethernet, you are limited to how fast the fog server can send data stored on its local disk. If you are using a server with a single sata disk, I would expect about the same transfer rates for a single deployment and if you were deploying 2 or more systems using unicast probably I might expect about 10 to 20 MB/s transfer rates.

So if you want to go fast deployment for multiple targets using unicast. Setup a bonded or LAG interface. Use a sata raid controller with 2 or more SSD drives configured with a stripped (raid-0) array, and have great and frequent backups.

[mitzayapa]

Right now the server we use ain’t a real server , just an old dell 790 desktop (at first fog was just an experiment for us) with a 7200 HD sata drive. It runs a ubuntu 12.04 server and fog 0.32.The speed we get is about 2-3 gbps in unicast , dropping with each client added.The “server” is connected to a 24 port ovislink gigabit switch. All this change to version 1.20 came up with the idea of changing the server with a hp 8200 tower , with an i5 and 8 gigs of ram and 4 x 128 raid0 disks.

What should we look into after installing the new “server”.

Thank you for your very useful information

[george1421]

2-3 GB/s is not bad, I think I’m getting in the 3GB/s (maybe 4GB/s) for a virtualized server. So what you have today is not bad.

From a performance wise there is not a lot you can do, since the fog server it self is not that busy during OS deployment. It is just moving data between the disk array and the network adapter. Having multiple spindles (disks) on your FOG storage array will help to speed up the disk part of the operation. Using SSD drives for the image and snapin storage would be better, if you wanted to use spinning disk for the OS. The client is doing the heavy processing by decompressing the target image as it is put onto disk. Having a fast disk subsystem and a fast network (LAG group if you will be imaging more than one at a time) .

BUT if you will image more than one machine at a time and they are all the same OS you can use multicasting and upgrade 25 machines at once, only consuming the network bandwidth of deploying 1 unicast image. Moving to 1.2.0 opens new doors for you.

[mitzayapa]

I would gladly update to 1.20 but the “quick image/host registration bypass” keeps me from doing it. I really need that option because the install process has to be fast (we do “on the spot” installations), we have 9 different windows images from 9 to 27 gigs , and registering every single client ain’t an option.

Is tweaking 1.20 (to make “quick image” available) hard? and i forgot to mention the 128 disks are SSD.

[Quazz]

This post is deleted!

[george1421]

One thing we found is that the default compression for image capture and deploy on the older versions of FOG is level 9 (high compression) Under 1.2.0 (trunk build) is 6 (faster decompression but larger image size on FOG disk).

I did tweak the fog boot menu for fog 1.2.0. My tweak added the pxe menu entry but selecting the quick image just causes the pxe menu to reboot. So no joy for my hacking skills.

[Wayne Workman]

@mitzayapa said:

I would gladly update to 1.20 but the “quick image/host registration bypass” keeps me from doing it. I really need that option because the install process has to be fast (we do “on the spot” installations), we have 9 different windows images from 9 to 27 gigs , and registering every single client ain’t an option.

I have 22 images, all are 40 to 50 GB. I have 500 hosts in my building - they are all registered.

Some of the FOG users here have 6,000 hosts.

I think you are mistaking that this registration needs to happen all at once. it does not. Register as you image.

I also image “on the spot” - and a registered client in FOG Trunk will be done far before an unregistered one.

Automatic naming
Automatic domain joining
Automatic Windows Activation
Automatic printer deployment

Just imaging a 45GB image on Trunk takes 5 minutes, the booting and rebooting and activation maybe 2 minutes.

Can you beat that, doing it all manually? I really doubt it.

You need to try out FOG’s features. They will SPOIL you Rotten, I tell you!

I can image 30 PCs at once and just walk away and not worry about it. I’ll come back later and their all imaged, named, on the domain and ready to rock and roll.

My next goal for this summer is 500 computers in a day - using a combination of unicasting and multicasting.

[Wayne Workman]

I don’t mean to come off harsh. but the way you put it makes how FOG is designed to work unacceptable or worse than doing it manually. I assure you this is not the case.

If you’re a used computer distributer and just want to stick a quick image onto computers for resale or shipment, then quick image is the best choice. You can do this in 1.2.0 using the Capone plugin, FYI. But you won’t see the massive speed increases that FOG Trunk has to offer.

If you support a set of computers through their life cycle - you should be registering computers.

And depending on how you are using FOG (virtualized, isolated, or bare metal) - then Trunk just might be good for you.

[mitzayapa]

I’ve decided to go on with the trunk version , had some issues at first but now its installed and i’m now uploading all images i have and recreate the ones that were old. I’ve bonded 2 nics and now i wonder , do i have to configure fog to work with bond or just install fog with the bond0 when asked.

Olso i would like to ask you guys , maybe some of u knows how to do it, how to add an entry to boot “system restore” by command (like in setupcomplete.cmd) cuz i set it up with easybcd in sysprep , but each time i install windows it goes away. (recovery partition has an extracted windows iso and easybcd points to boot.wim).