PXE image looping

[george1421]

@ManofValor If you do as I suggest just create a 20GB vmdk for the OS. The OS only really needs about 5GB, but leave room for updates and such. Once that is done go back in and create a new vmdk file for your storage. Make it what ever size you need today. By putting the images in their own vmdk file you can dynamically grow that disk as you need to as time goes by.

Once you have that second vmdk file (will probably be listed as /dev/sdb) you will need to partition it with fdisk and then format it as ext4. Once you have that disk you need to attach it over/to the /opt directory so it mounts every time (using /etc/fstab file).

Once you have that new vmdk attached, then you can install fog and tell it to put its images in /opt/fog/images

This will be a great learning experience for you. Google is your friend.

[Wayne Workman]

@george1421 Solid advice, absolutely, and would work fine too.

I would prefer though to mount the 2nd hdd to /images because /opt/fog/images is a deviation from the expected. And because /images would be the expected location for all of our documentation, all of our forums posts, and any future advice we give out, and any tech with previous fog experience coming into an environment to take care of FOG would expect the images to be in that location, and the installer uses this location as default.

But again, nothing mechanically or logically wrong with moving it to /opt/fog/images, it’d be perfectly functional and equally as expandable in the future.

[ManofValor]

@Wayne-Workman What partitioning scheme do you recommend? I’ve been trying to look up the difference between the four options I have (standard, btrfs, LVM, and LVM Thin Provisioning). I was thinking standard for the OS and LVM thin for the images?

This is question for all.

[Wayne Workman]

@ManofValor LVM is easier to resize later. However, all can be resized, just the older the scheme the more difficult it is. You might want to hold off till @george1421 chimes in.

[george1421]

@ManofValor LVM is the way to go. But you still want to move your FOG storage off your root LVM, or if you fill it up you will have the same issue as if you had everything on the same partition. *nix does not like it when you fill up the root partition. When you do this, you will never have a happy ending. But if your images are on a different LVM or disk that is attached to your root partition then you can fill up that disk, but it won’t whack the root volume. Its kind of complicated how it is setup.

If you want to think about it in MS windows terms. The root disk/partition is like the drive and we will connect a new disk to the folder C:\opt. When you change into the C:\opt folder behind the magic curtain windows will seamlessly transition to that other drive.

[ManofValor]

@george1421 So for the install just do the 20 GB and then do the other one later after the install? I’m not trying to set this up as a VM, isn’t that what a vmdk is for? This is a physical server.

[george1421]

@ManofValor Sorry I shouldn’t think the whole world is virtualized.

On your server do you have a single disk, array, or what?

[ManofValor]

@george1421 Single. We are mostly virtualized, but not for this yet.

[ManofValor]

Using the install GUI, do I do it like this:

Manually partition OS with LVM at 20GB mounted on /boot using ext4

Manually partition storage, for images, with LVM at 450GB mounted on /opt/fog/images using ext4

Something along those lines?

[Wayne Workman]

@george1421 said:

Sorry I shouldn’t think the whole world is virtualized.

I was just going with the flow lol.

[ManofValor]

This post is deleted!

[Wayne Workman]

@ManofValor It’s not a fog question. It’s a Linux question. If CentOS 7 supports it (or any other distro of Linux), then fog can use it.

[ManofValor]

@ManofValor

[Wayne Workman]

@ManofValor Looks good, the only suggestion I’d make is making the /boot partition 1GB. Who knows how long you’ll use this server?

Once I helped with a Ubuntu server that was literally out of space on it’s boot partition… We only got by because I found some older kernels to delete!

[george1421]

@ManofValor I know its probably too late, but I would have done the /opt mount point instead of /opt/fog/images. That way all of the opt stuff would go into that 400GiB drive. What you won’t get is /opt/fog/snapins that will still go onto the root partition. Sorry I was late, stuck in a teleconf call for 2 hours.

[Wayne Workman]

@george1421 said:

I know its probably too late, but I would have done the /opt mount point instead of /opt/fog/images.

It’s not too late. I’d say go back and do it right.

[ManofValor]

@george1421 I haven’t gone any farther than the pic. Waiting to make sure I do this right.

[george1421]

@ManofValor Ok then just change the mount point to /opt and you should be good to go.

Linux (*nix) is a bit confusing for the windows folks. As windows gets older it gets more features like *nix. This whole mount point is cool once you understand it. Its a bit like what DFS is but on a local hard drive concept. You can traverse between hard drives or network shares for that matter, but just changing to a different directory. From the UI level there is no drive or d: drive. The d: drive would just be mounted to a directory and you would change into that directory for data to go onto the d: drive.

[Sebastian Roth]

@george1421 Why using /opt/fog/images? As Wayne already said: “I would prefer though to mount the 2nd hdd to /images because /opt/fog/images is a deviation from the expected.” Both will work, but sticking with the default (/images) might be wise as well. @ManofValor Up to you.

[george1421]

@Sebastian-Roth The logic is that the snapins (which could also be huge) would not be captured if only /images were mounted over on the new disk. My preference would be to keep EVERYTHING fog related in /opt/fog. (But I’m one of those type ‘A’ people, so that that for what it is. )