diggory

Looks like something must be corrupted with my installations or database - time to reinstall the server and FOG.

Ok I tried uploading a larger image - didn't work. However there were two other variables: The small image was a newly created one. The large image wasn't (existed before). The large image also has a "." in the file name.

I'm having the same problem. I've checked a few things, The storage password and ftp config seem ok. I've watched fog create the image file in /images/dev However it seems when it comes to move and rename the image file to /images it come up with the rename error on the console of the machine uploading. I checked the right on the directories (/images and /images/dev) They were set correctly, but I ran thease commands just in case: chown -R fog:root /images (Adds file ownership for fog and group ownership to root to all images dir and below). Still didn't work. The file seems to get deleted rather than moved. So, I've tried adding global write access (security risk of course) with: chmod -R 777 /images This has worked on a small image upload (~2G), just trying a larger one (~30G) The specs of my system: Virtual machine, running debian5 FOG version 0.29

I don't think it loads balances exactly. Rather it will only image a certain number at a time, the rest will sit in an orderly que. You can reduce the que size as morganw mentioned. Have a look in the about menu, then the advanced settings, search for FOG_QUEUESIZE, you can then adjust the number of machines FOG will image at a time. You might have to restart the FOG server (or service) after that - although I'm not sure if that's required.

Had a PXE boot problem with some old ASUS laptops I wanted to FOG. The only way I could get round the buggy PXE boot rom was to use a PXE boot CD. Try this web site for a handy ISO: start - Etherboot/gPXE Wiki It might rule out if the PXE rom is an issue.

Sometimes multi-casting can be slow if you have a big broadcast domain. (For ghost at least...) We don't use multicast too much here as we have +400 machines on they same ethernet segment - sigh.. You could try a work around to see if a smaller segment speeds things up by plugging in only the switches you're going to multi-cast to and the fog server. If it's much faster - you know it's a ethernet broadcast thing slowing up your fog multicasts. Or you can try using a packet sniffer if you know what you're looking for...

Trunking is ok for the LAN only side.... however you shouldn't use it for your iSCSI traffic. Have a look at this article for setting up iSCSI in VMWare. A Multivendor Post on using iSCSI with VMware vSphere - Virtual Geek

We've got it running between buildings here. Using VLANs (of course) to separate the iSCSI traffic out from the normal LAN traffic. We are using it for backups, so high traffic is out of hours mostly.

Your master DC for time (the PDC/PDC emulator by default) will be the one with a ntp running. You can query it with the w32 command in the cmd console: w32tm /monitor That should show you which of the DCs is the master time controller in your domain. There are some other options for the w32tm command which are handy for checking the sync etc... A lot of the settings can be set with group policy.

We had the same problem. The 2600 would keep kicking the print spooler off-line. We took it off the printer server eventually and resolved never to put it on again (ran locally after that with few issues). Running windows 2003 for our print server.

Sorry I didn't fully explain my post. I you have already imaged a machine in FOG and want to change it's name... You could sysprep the machine - which would take it off the domain and give it a random name (when it boots into the sysprep setup). [This assumes you have a sysprep.ini which is fully automated - which is the usual way with FOG images..] Then before the machine is booted.. Have a look at the (already registered) machine entry in FOG. Change the name there. Boot the machine. The FOG service on the machine will then change the name of the machine, from the random name (given by sysprep earlier) to the one you changed it to in FOG (as ssx4life mentioned - it will use the mac address to match the name up in it's database). The FOG service will then join the machine back too the domain. Job done?

Does DPM handle tape changers ok (yeah old school I know...) DPM 2007 made real hashups with our's and we can only use it for disk-disk. Have to use bacula for tape.

If you need to rename a PC without re-imaging it, then let FOG do the hard graft. sysprep the machine - by default it will turn up a random name. BEFORE the machine boots after that, change the name of the PC in FOG. Then the FOG service will rename the PC and rejoin it to the domain for you. Otherwise you're fighting the FOG service.

Have a look on the FOG wiki... you can use the backup routine to backup the SQL data base and then copy across the file and restore it on you new server. You can also copy across the images using the rsync command...

I'd avoid the openfiler SAN for iSCSI. I was running OF on 4 SANs. Was fine until I had it running under high loads and then would freeze up (which is bad news for VMWare). I've installed nexenta on my SANs now - seems stable under high loads. However the RAID card on one of my SANs broke (sigh). It's worth having redundant everything on a SAN if you are going to have several important servers running from it. Also worth noting in VMWare that unstable SAN can cause the vHosts to become unresponsive and possibly freeze up virtual servers that aren't even on that SAN. (Again from experience...) Backups are very much more valuable. I'm running MS DPM and VMWare Data Recovery.