PfSense VMware-Ready Virtual Firewall Appliance Feedback
-
I looked in my datastore and found this version, gparted-live-0.20.0-2-i486.iso
-
Have you had luck with any particular version of GParted?
According to gparted doc, it does not support resizing ufs, only move and copy
Attachments seem to be a problem so
http://gparted.org/screens/gparted-file-system-support.pngYou can try a live resize with gpart in pfSense
$ gpart show => 63 16777153 da0 MBR (8.0G) 63 16771797 1 freebsd [active] (8.0G) 16771860 5356 - free - (2.6M) => 0 16771797 da0s1 BSD (8.0G) 0 16 - free - (8.0K) 16 14674629 1 freebsd-ufs (7.0G) 14674645 2097152 2 freebsd-swap (1.0G) -
Thanks again. I grabbed that version from sourceforge, no dice. It doesn't recognize the partition type so it can't work with it. I tried doing this in single user mode using gpart, but that doesn't work either. I'm going to try goinging through the OVA deployment again, and editing the VM before finishing the wizard, see if it will work. I doubt it, but it's worth a shot.
-
I tried doing this in single user mode using gpart, but that doesn't work either.
Care to define gpart doesn't work?
-
Sorry, that was a terible thing to leave hanging, you are right. I actually HAVE manged to get it to work (I think) with gpart, but I was attempting to follow these instructions and having no luck:
http://unix.stackexchange.com/questions/117023/expanding-the-disk-size-on-pfsense-under-vmware-esxi - turns out I was missing the "a" on the end of the growfs command, and there is a reboot that I had to do that is not in those instructions.
Now, I know that growing a live partition is supposed to be possible in freebasd 10 and up, but I haven't found anyone doing it on the pfsense forums yet, so I just booted into single user mode JIC. I make NO promise that this is correct, this is just what worked for me!!! Backup everything! You have been warned!Here is what I ended up doing - I'm going through it again on a second firewall to make sure it wasn't a fluke.
On boot up, hit the space bar as soone as you see the pfsense ascii art "Welcome to pfSense" menu.
Choose option 6 to configure boot option, hit m to turn on safe mode, hit s to turn on single user mode, then hit Enter.The thing boots, and eventually asks you for the full pathname of shell or hit RETURN - just hit return (Enter)
you should now be at a # prompt. cd /sbin to get into the directory with gpart.
do a ./gpart show. This is what I get:
What I took away from this were the names da0 (/dev/da0) and da0s1 (/dev/da0s1a=freebsd-ufs and /dev/da0s1b=freebsd-swap). I honestly don't remember where I saw the da0s1a and s1b, but I have seen it and it becomes importnat later :)
so, the Master Boot Record (MBR) has 20 gigs free. We need to get that combined with the 5G partition listed above it.
./gpart resize -i 1 da0
followed by a
./gpart commit da0s1
like so (minus the mistake where I forgot the ./)
if we do a ./gpart show again, now we see this:
More like it, da0 is now 25 Gigs.
Now, see that all the free sapce in da0s1 is after the swap file. so, we're going to delete the swap partition (and re-create it later):
./gpart delete -i 2 da0s1
results of that and another ./gpart show
EDIT: sory, the source of this screen shot broke :(
now, I have 4 gigs of RAM in my system, and so I wnat an 8Gb swap. I'm going to tell the system to re-size da0s1 to (25G-8G) = 17G
./gpart resize -i 1 -s 17G da0s1 the ./gpart show
Now we have re-sized the partition, and we have got 8G left unallocated at the end for the swap. Before we do that, we need to grow the filesystem:
./growfs /dev/da0s1a
at this point, that command gives me a "operation not permitted", so I type exit and it "finishes" booting into pfsense. I then choose option 5 to reboot.
Once again, as soon as the ASCII art menu comes up, hit the spacebar to prevent further booting. Again choose option6, then hit m and s followed by enter to boot into single user mode.
This is where it might be a little scary - the system won't boot into the shell - instead, you see this:
simply type in
ufs:/dev/da0s1a
and hit enter, then hit enter again to get to the # prompt.I change into /sbin again, and issue ./growfs /dev/da0s1a again:
and a gpart show after:
Now we need a swap file again:
./gpart add -t freebsd-swap da0s1
After that, I activated the swap by issuing ./swapon /dev/da0s1b , but rebooting should take care of it.
I type exit and hit enter to reboot, then do an option 5 once the console menu comes up to reboot again. After a normal boot, choose option 8 to get to the command prompt and do a gpart show (it's in the path now), and you should see your expanded partition.So far, it hasn't given me any trouble. If I've made any obivous mistakes in here, please let me know.
EDIT: now with actual pictures
-
I have tried it myself and you are right, it seems FreeBSD is using UFS and gParted is only able to detect it.
Sorry about giving wrong advice :( It seems Freebsd only has those 2 commands, gpart and growfs.I use sometimes Clonezilla, perhaps you can use it to clone it to bigger disk, but please I am not sure this time.
The 5GB disk seems a bit tidy, not sure how this would work ut on my VMware machines with loads of traffic and additional software in pfSense installed… I am a bit worried about that. Did you find out if you could do something with the .ova file?
-
ok, i added 15GB to the disk, if I recall in right way, I did as follow.
In vmware I added the 15GB extra to the disk.
Login shell in fSense.gpart show
I can see the 15GB extra space but on wrong place da0 instead of da0s1
gpart resize -i1 dao
gpart commit da0s1 [commit the change]
gpart show [now I can see the etra space and correct place, but we need to add it to the ufs partition. sadly in my case the swap is in the way for a nice aligment, so i got rid of the swap partion, then resize i1 [index 1] is the ufs partition we want to extend but we add only the space we want minus the swap as we need that back 2GB it was in my situation…swapoff -a [disable swap]
gpart delete -i2 da0s1
gpart show [now you see the swap gone so, we can extend the partition]
gpart resize -i1 da0s1 -s [your size to add in notation xM xG]Done, add your swap back and reboot.
Hope this helps.
** Don't do this with a mounted file system ;-)
I didn't mind to do it as I wanted to help you.Oops, whilst I was busy to do this you worked it out yourself as well…. well done!
-
Not sure if you really need 8GB swap, with 4GB RAM and 4GB Swap you will run very smoothly.
The rule twice RAM = SWAP is a bit old fassion ;-)
But it might be still good with FreeBSD and pfSense in combination with each other.
-
Heh. You are probably correct there. But the way the image came was with 512Mb of ram configured, and a 1Gb swap partition - so I simply maintained the same ratio.
When i initially created my 2.1.5 image that I use in "production", I had 8 gigs of ram and the setup reserved 5 gigs of disk space for swap, and I simply chose the defualts presented to me.
-
I have no idea why a VMware ready image is so 'limited' in resources, after all when using it in our production servers we want to add quite a lot to it. Just curious how different this image it is in comparing it with a 'normal' VM installation, does it have some intellect on board. I noticed your remark about the NICs and VMXNET3, but for that you need VMware tools and not sure if the open-vm tools can address that. Have you done some proper testing?
-
I have no idea why a VMware ready image is so 'limited' in resources, after all when using it in our production servers we want to add quite a lot to it. Just curious how different this image it is in comparing it with a 'normal' VM installation, does it have some intellect on board. I noticed your remark about the NICs and VMXNET3, but for that you need VMware tools and not sure if the open-vm tools can address that. Have you done some proper testing?
FreeBSD 10.1 includes drivers for vmxnet3, the tools are no longer required for that. The VM appliance comes preconfigured for vmxnet3 interfaces.
5GB is not "limited" for what most people use pfSense for inside or outside a VM. It may not be enough for a large web cache but that is not as common a role as one might think. Adding a second disk to the VM is another option, though also manual, it would likely be less work/fuss than resizing the existing disk/slice. Just partition/newfs the second disk, make a mountpoint, and add it to /etc/fstab
In terms of RAM sizing it has to be fairly low to play to the lowest common denominator but that's simple for people to change.
-
Thanks jimp. I totally agree - i am an outlier, in that I've got specific needs that require me to have some more space on the device in case the remote logging goes offline for a period of time - don't want the box to fill up and likewise don't wnat to lose the logs. My "home" pfsene box is running with 2 gigs of ram and a 4 gig USB stick for storage, nanobsd version of pfsense, and works a treat, even on a crappy old atom CPU. The defualts chosen should work fine for many people, as you say.
I should test adding a second partition - I am using the syslog-ng package to feed encrypted logs to a remote system, and I'm also keeping those syslog-ng logs local for a period of time. I don't know if I can tell the package to write someplace other than the default location, if I can I'll simply add the partition and go.
-
Has anybody managed to deploy the OVF Image with the VMware vSphere web client? I get an error saying that the OVF package might be invalid.
As there were no MD5 or SHA1 sums on the gold portal download page, I can't verify if the download is broken.Anyway the SHA1 sum of my OVF image is: 80bc8c9feab42afe2a65c9fafcb8bbfd8fbeb401 pfsense_2.2.2__34019.ovf
Deploying OVF images from VMware (e.g. vSphere Operations Manager) works without any problem, so I think there is an issue with the image.
-
I haven't tried that myself, though we use that internally so I think that was tested but I'd have to confirm with the person who made the image.
The SHA1 appears to be correct, here are some other hashes for that file:
MD5: 0d15cb0132f86e44b794f52d5f4713ac
SHA1: 80bc8c9feab42afe2a65c9fafcb8bbfd8fbeb401
SHA256: 05f1cbd673b50178067d6dddf44abfd5798c68dc78a47c1a789127d17fbafafc -
…This is where it might be a little scary - the system won't boot into the shell - instead, you see this:
simply type in
ufs:/dev/da0s1a
and hit enter, then hit enter again to get to the # prompt.I change into /sbin again, and issue ./growfs /dev/da0s1a again:
and a gpart show after:
Now we need a swap file again:
./gpart add -t freebsd-swap da0s1
After that, I activated the swap by issuing ./swapon /dev/da0s1b , but rebooting should take care of it.
I type exit and hit enter to reboot, then do an option 5 once the console menu comes up to reboot again. After a normal boot, choose option 8 to get to the command prompt and do a gpart show (it's in the path now), and you should see your expanded partition.So far, it hasn't given me any trouble. If I've made any obivous mistakes in here, please let me know.
snm777's instructions worked for me! Thanks!
Couple of additional issues
Got a warning that the swap file size was larger then the kernel config allowed.
Backed it down to 4GB and it was fine.
Steps:
./gpart delete -i 2 da0s1
./gpart add -t freebsd-swap -s 4G da0s1
./swapon /dev/da0s1b
./exit
hit enter to reboot
option 5 once the console menu comes up to reboot again.
After a normal boot, choose option 8 to get to the command prompt
./gpart show
No further complaints about swap file size.I also got the mountroot> issue every time I rebooted.
I mounted using smn777's mount command: ufs:/dev/da0s1a
Once pfsense was running I looked at fstab and foud some strange entries for the root and swap partitions.
I performed ls /etc nd saw that thee was fstab and fstab.old files using vi.
I looked at fstab.old and the entries were what should have been in fstab.Device Mountpoint FStype Options Dump Pass#
/dev/ada0s1a / ufs rw 1 1
/dev/ada0s1b none swap sw 0 0
I replaced fstab with fstab.old
./mv /etc/fstab /etc/fstab.old2
./mv /etc/fstab.old /etc/fstab
After that, I was able to reboot successfully.
