Posts made by scgsg

This may have come up before, I wanted get legacy to work with uefi so on my windows 2016 dhcp server i configured a policy for legacy (vendor PXEClient:Arch:00000) and set 66 + 67. The client loads and gets to bit where it gets an ip address but after a while fails with ‘PXE-E53: No Boot Filename Received’ so it looks like the policy works in part. Ok now here’s the weird bit, instead of using a policy, if I set the options directly as DHCP options with the same settings it works perfectly fine.

Any ideas whats going on here?

I see thank you for explaining that.

This may have been asked before so apologies if the case. What is the effect of changing the Master Node Storage Group i.e. if the Master node is in the default group and you change it to a new group that has less images in it, will this cause a problem? I dont think it would be but need to check in case for some reason it causes it to delete any images that are not part of the same storage group.

@Sebastian-Roth ah ok thanks for the advise and sorry I missed that. I’ll give that a go once deployment is complete.

Server

• FOG Version: 1.4.0
• OS: Ubuntu 14.04.5

Description

This isnt a problem really, just a query… for some reason int Storage Group Activity, it shows 1 active for default when there are no tasks, and this affects max clients. Is this expected?

Thank you for the advise, I’ll keep that in mind.

This is a query (not a problem), what should I be aware of regarding deploying to hdd and ssd. That is, should I use 2 different images or can I use just 1? If I create the image on a computer with a hdd and use this images to deploy to an ssd, what should I be aware?

@Wayne-Workman Thank you, sorry I missed this article when I looked for answers earlier.

Regarding the connection indicator under Host Management, how does this work? i.e. how does fog identify ‘Success’ or ‘Connection time out’? FYI fog server version is 1.4.0.

UPDATE: I assume its based on ping to hostname, how is the data refreshed? or is this checked on a schedule?

Just a quick question, where are all the places i should be aware of if i want to change the fog user password i.e. so far I’ve noted the following:

1. Fog server local user i.e. in my case its a linux user so can change password with passwd.
2. In the WebUI
   a. User Management
   b. Storage Management > Node
   c. Fog Configuration > Fog Settings > TFTP Server

Are there any other places where the fog user password is stored?

@Wayne-Workman Thank you for taking the time to look into this, and I’ll just chalk it up to weird things that happens to me. Thank you for all your efforts and advise.

@Wayne-Workman Ah Ok, sorry formatting of the post didnt make it very obvious as i tried to make it like a table. Anyway hopefully this is clearer:
Image1 Settings before capture
Default Storage group
Windows 7
Multiple Partition Image - Single Disk (Not Resizable)
Partition = Everything
Level 3 compression
Image Manager = PartImage
Image1 Deployment Times
16min 29secs
16min 27secs
16min 29secs

Image2 Settings before capture
Default Storage group
Windows 7
Multiple Partition Image - Single Disk (Not Resizable)
Partition = Everything
Level 3 compression
Image Manager = PartClone
Image2 Deployment Times
18min 30secs
18min 30secs
18min 27secs

The Fog server is 1.4.0 and all image deployment and capture is done on this server. Everything else remains constant i.e. no changes to fog server other than changing which image client uses, same switch (no configuration changes), same client and settings as detailed above. The deployment times are pulled from the Imaging Log and are the actual times recorded.

I can confirm that both images capture with partclone and both deploy with partclone, with both images having the exact same size on server so both images should clock similar times but oddly enough image1 clocks 2mins faster (with the only difference being the Image Manager for Image1 set to PartImage for capture).

@Wayne-Workman Not sure what you mean, I’ve given details for the settings for Image1 and Image2 so what settings are we talking about?

@Wayne-Workman Ok this really is odd, as stated I’ve created 2 images with everything the same except the Image Manager setting before capture and there is a difference in deployment times. Here is what I did:

Capture Images:

1. Deployed the old image (created originally in partimage from fog 0.32) and set to shutdown after deployment
2. Create a new Image in Fog with the following setting to match the old image:
   a. For the purpose of testing lets call it Image1
   b. Default Storage group
   c. Windows 7
   d. Multiple Partition Image - Single Disk (Not Resizable)
   e. Partition = Everything
   f. Level 3 compression
   g. Image Manager = PartImage
3. Capture new image and set to shutdown after deployment
4. Deployed old image again and shutdown after deployment
5. Create another image in Fog with the same settings as above but call this Image2 and Image Manager set to PartClone
6. Capture this image and set to shutdown after deployment

NOTE: Captured images are exactly the same size on the server (35061064).

Test Deployments:
Each deployment is set to shutdown after deployment.

1. Deploy Image1
2. Deploy Image1
3. Deploy Image2
4. Deploy Image2
5. Deploy Image1
6. Deploy Image2

Here are the results:
Image1 Image2
16min 29sec 18min 30sec
16min 27sec 18min 30sec
16min 29sec 18min 27sec

Again still not really a large enough sample to be definitive but does seem to imply an odd pattern.

@Junkhacker Yes fair point and the client I’m using is one from the network with the majority clients being the same or equivalent.

Interesting, that certainly gives me an idea as how to approach zstd images when i start looking at this.

Ah ok, thank you for clarifying.

@Tom-Elliott Wanted to say that I hope haven’t in anyway (either by implication or statement) come across as negative or complaining. If I have, that’s my bad as I think this project is great and I am very thankful for all your hard work. My intention was actually to see if it was expected behavior and/or maybe find the best way to get the most efficient deployment strategy.

Thank you for pointing out the main things that can/will have an impact on speed.

1. The gig switch only has the 2 test pc, vsphere host (that the fog server sits on and there are no other VMs on this host) and a connection to the rest of the network. The gig switch has default config on it, is there any particular config i need to pay attention to? given that I havent used multicast deployment in any of my tests.
2. I will keep that in mind particularly with our older machines but at the moment all tests are done on the same pc
3. Will keep that in mind too.
4. I think i intend on using ZSTD ultimately but havent for my tests at the moment as capture speeds are very slow i.e. with compression set at 6, it was over an hour to capture.
5. Interesting, can I clarify your statement ref max compression, is it not recommended for any zstd or recommended for zstd. I assume its not recommended due to the reasoning given, and what would you say is the optimal compression level on average (I realise this is dependent individual cases and environment and you probably cant give an answer).
6. Will keep this in mind too but plan is to have client on the same switch where possible.

@Wayne-Workman Well initially i was testing difference between old partimage deployment vs a new partclone deployment so initial partclone captured deployments times were used as a comparison against the later partimage setting captured deployments (yes i know its actually a partclone capture so there should be no difference). Everything is set the same and the only thing different is the image manager setting. Currently this would be 4 deployments where partclone was set and 4 deployments where partimage was set. I wouldnt say the sample is big enough to be conclusive but is what i have at the moment. At the moment I am in the middle of retesting all of it by creating another 2 images, 1 image is captured with partimage set and the other is with partclone set. Everything else remains the same i.e. same client, same image settings (except image manager setting), same switch with the same config, same process of capture (as described by Tom earlier, post 8 ) etc.

Thank you for all the responses, i’ve been away for a couple of day and didnt get a chance to look at this. ZSTD is certainly quicker on the 1 test I did but i havent tested any further as it took over an hour to capture. Still it was only as quick as my most recent test with partclone gzip.

@Junkhacker yes I am aware captures are no longer done with partimage and that is my point, if i configure it as partimage, the capture is done in partclone (and it will change the setting to partclone after capture) but deployment is quicker than an image captured with image manager set to partclone. I dont know why that is, I’ve done a number of tests now and each time the deployment is 2 mins quicker. I cant fathom why 1 setting, which ultimately make no difference in the capture of the image, will deploy quicker.

@Junkhacker I did try zstd in one of my earlier tests and it clocked in at 15min 33secs so it is quicker. I’m not 100% sure but i think i left compression at default 6. I didnt test this any further because it took 1 hour 6 mins to capture the image. Testing this one for optimal compression is going to take a while.

Fair enough, if thats expected behavior between partimage and partclone, it is what it is and as you say a moot point. Furthermore its not like i can capture with partimage anyway. That being said, i have a real head scratcher with my latest test. By chance I captured a new image with image manager set to partimage and it captured using partclone so no surprises there. However heres where it gets odd, I deployed this image and its clocking in at just over 15 mins. I’ve done this 3 times now, twice to 2 computers at the same time and once to just 1 computer. Deployment times were between 15-16 mins. In between these tests i did retest deploying an image that had been captured with image manager set to partclone, and the result was 17min 35sec (similar times as before). This is confusing, why would setting image manager to partimage create an image that is faster to deploy? this is even more confusing as I checked the file size on the server for the captured images (one set to Partclone and the other set to Partimage for capture) and they are exactly identical. I really dont understand how I can get image deployment 2 mins faster just because I set it to partimage for the capture, given that it doesnt capture using partimage and uses partclone anyway. Any idea what the heck is going on there?

@Tom-Elliott Don’t suppose you have any suggestions? be it server config or switch config or something? I am somewhat at a loss as to why higher compression equals faster deployment (or so it seems) but the size on server remains pretty much the same so the increased speed is not due to smaller file transfer. Not entirely sure how this impacts on deployment to multiple computers.

@Tom-Elliott Interesting, this time deploying the old PartImage image was 12min 32secs (pretty much expected) and deploying the PartClone image with compression set at 3 clocked in at 17min 9secs (not majorly different from compression set at 6). Whats even more interesting is that I also did a test with the compression level at 9, that clocked in at 15min 47secs and the PartImage deployment clocking in at a 12min 21secs. This is strange as the size on server isn’t hugely different between compression set at 6 and 9 (both rounded to 34GB).

With all that said it still looks like PartImage comes in faster, this obviously isnt conclusive as I’d need to do a lot more tests but it certainly implies a pattern. Thing is, I’m not sure how this would impact deployment on a larger scale i.e. just because PartClone takes longer it may not necessarily affect the deployment on a larger scale in a negative way but potentially the extra 5 minutes it takes could mean it will take even longer to deploying to a larger selection of computers with slower specs and LAN speeds. Something that use to take half a day may now take the entire day due to this?