Fog 1.20 as 0.32
-
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.
-
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?)
-
@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.
-
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
-
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.
-
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.
-
This post is deleted! -
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.
-
@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 deploymentJust 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.
-
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.
-
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).
-
@mitzayapa Our init’s come with a generalized BCD file in the case of “resizable” which is likely overwriting your customized BCD file.
I think we can correct this on your init’s so long as your BCD’s are setup in a generalized state.
-
@mitzayapa As to the nic bonding question. If you are doing a unicast deployment between a single target computer and the FOG server bonding will not add any value. The data is not multiplexed across the members of the bond/lag, so once a network link is selected the conversation between the FOG server and target computer will remain on that selected network link.
Where bonding/lags help if you are doing a unicast deployment to multiple targets at the same time. Think of a bonded/lag connection as a highway. You can add more lanes to carry more traffic, but you still can go only the posted speed limit and you must remain in your lane once the lane is selected.
In regards to your question about telling FOG to use the bond. The nic bonding is setup at OSI layer 2 so the bond is transparent to FOG and to a certain extent the OS too. So there is nothing to do in this regards.
-
First of all: Happy New Year guys
, now i have a problem you guys might give me a hint how to solve.I´m now testing trunk version , 5704 , every i want to image a client , i choose the image through quick image , select the image , then it gives me a black screen and freezes.This has to do with an external router that i have , because if i disable dhcp on that router works like charm.
The thing is i need that routers dhcp enabled, please point me in the right direction how to solve this.
thank you in advance
-
Please start a new thread since your issue will get lost in this thread’s title.
But it sounds like you have two dhcp servers running in your environment.
