I have some development projects that require a large amount of disk on the VM, and are running into issues with the current centos/7 Vagrant box. Is it possible to increase the disk size of the Vagrant image to 100, or even 200 GB? Since this is a sparse image, I don't believe the change will have any affect on people using less disk space, it will only use up as much space on the host system as is in use on the VM.
Laurențiu, what do you think?
Thanks, Jeff
On 17/08/17 21:33, Jeff Sheltren wrote:
I have some development projects that require a large amount of disk on the VM, and are running into issues with the current centos/7 Vagrant box. Is it possible to increase the disk size of the Vagrant image to 100, or even 200 GB? Since this is a sparse image, I don't believe the change will have any affect on people using less disk space, it will only use up as much space on the host system as is in use on the VM.
would this be / could this be a problem that it might fill up the host machines disk
----- Original Message -----
From: "Jeff Sheltren" jeff@tag1consulting.com To: "The CentOS developers mailing list." centos-devel@centos.org Sent: Thursday, August 17, 2017 10:33:33 PM Subject: [CentOS-devel] Disk size on Vagrant image
I have some development projects that require a large amount of disk on the VM, and are running into issues with the current centos/7 Vagrant box. Is it possible to increase the disk size of the Vagrant image to 100, or even 200 GB? Since this is a sparse image, I don't believe the change will have any affect on people using less disk space, it will only use up as much space on the host system as is in use on the VM.
Laurențiu, what do you think?
You can use additional disk[1].
[1] http://everythingshouldbevirtual.com/vagrant-adding-a-second-hard-drive
HIH, Pavel
Thanks, Jeff
Adding additional storage in Vagrant with Virtualbox provider is a can of worms:
https://github.com/aidanns/vagrant-reload/issues/6 https://github.com/mitchellh/vagrant/issues/8107 https://www.virtualbox.org/ticket/16387
The situation is better with libvirt, so an additional disk may be an option in this case.
Marcin
On Fri, Aug 18, 2017 at 7:49 PM, Pavel Valena pvalena@redhat.com wrote:
----- Original Message -----
From: "Jeff Sheltren" jeff@tag1consulting.com To: "The CentOS developers mailing list." centos-devel@centos.org Sent: Thursday, August 17, 2017 10:33:33 PM Subject: [CentOS-devel] Disk size on Vagrant image
I have some development projects that require a large amount of disk on
the
VM, and are running into issues with the current centos/7 Vagrant box.
Is it
possible to increase the disk size of the Vagrant image to 100, or even
200
GB? Since this is a sparse image, I don't believe the change will have
any
affect on people using less disk space, it will only use up as much
space on
the host system as is in use on the VM.
Laurențiu, what do you think?
You can use additional disk[1].
[1] http://everythingshouldbevirtual.com/vagrant-adding-a-second-hard- drive
HIH, Pavel
Thanks, Jeff
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Fri, Aug 18, 2017 at 1:04 PM, Marcin Dulak marcin.dulak@gmail.com wrote:
Adding additional storage in Vagrant with Virtualbox provider is a can of worms:
https://github.com/aidanns/vagrant-reload/issues/6 https://github.com/mitchellh/vagrant/issues/8107 https://www.virtualbox.org/ticket/16387
The situation is better with libvirt, so an additional disk may be an option in this case.
Yeah, it's possible we could get a second disk to work, but that requires additional config management changes to mount it in the correct place, and keep our fingers crossed we can avoid bugs similar to those links across various dev host environments (out of my control). So I'd much prefer to have a larger disk in the base image if possible.
Regarding KB's point, I haven't tested that, but it seems possible this could lead to filling up the host machine disk -- of course that problem exists regardless of the VM disk size, it just may be more likely with a larger allowed guest disk size.
-Jeff
Hi Jeff,
sorry for the late reply, it's a pretty busy time at work for me.
On 17/08/17 22:33, Jeff Sheltren wrote:
I have some development projects that require a large amount of disk on the VM, and are running into issues with the current centos/7 Vagrant box. Is it possible to increase the disk size of the Vagrant image to 100, or even 200 GB? Since this is a sparse image, I don't believe the change will have any affect on people using less disk space, it will only use up as much space on the host system as is in use on the VM.
Laurențiu, what do you think?
It would be technically possible and, as you pointed out, the disk footprint of the current images wouldn't change much.
Our centos/7 image is around two times larger than Fedora Cloud (409MB vs 208MB for the VirtualBox variant). I would like to reduce our image size as soon as 7.4.1708 is released - it would make downloading the image and instantiating a new box significantly faster, as well as reducing our bandwidth usage (we have 4.5 million downloads so far). We have to uninstall some packages that Anaconda insists on always installing, but we don't regain the space used by those packages unless we fill the freed sectors with zeros. On XFS, we can only fill the entire disk with zeros using dd in %post (zerofree only works with Ext4 filesystems, which is what Fedora uses) - writing 40GB of zeros on our CBS builder would already be pretty bad, I wouldn't want to switch to 100-200GB disk images (the disk I/O is actually double that size, since the sparsify process would need to read the image file resulting from the installation).
Adding another disk to a Vagrant box is a somewhat fragile process, but resizing the existing disk image works pretty well and could be automated, I think. [1] You could also use Packer to generate customized versions of our official images for you own use - please see the vbox-packer branch in [2]. The latter is fully automated and takes less than 30 minutes on my Mac Mini "late 2009" with only 4GB RAM and a slow mechanical hard drive.
Best regards, Laurențiu
[1] https://www.laurentiupancescu.com/blog/591c105a/ [2] https://github.com/lpancescu/sig-cloud-instance-build
Any change of getting the guest additions installed with the vbox? Have looked at your ft branch and can't see the additions being installed and is a requirement for inclusion on the vagrant forge. I understand that the additions have to be compiled against the kernel, as we require this on my current project is we set up a pipe line to compile the additions against all kernels and drop them in an S3 bucket, you could do a curl at the end of the kick script to obtain the correct additions to match the kernel?
Sent from my iPhone
On 19 Aug 2017, at 07:03, Laurentiu Pancescu lpancescu@centosproject.org wrote:
Hi Jeff,
sorry for the late reply, it's a pretty busy time at work for me.
On 17/08/17 22:33, Jeff Sheltren wrote: I have some development projects that require a large amount of disk on the VM, and are running into issues with the current centos/7 Vagrant box. Is it possible to increase the disk size of the Vagrant image to 100, or even 200 GB? Since this is a sparse image, I don't believe the change will have any affect on people using less disk space, it will only use up as much space on the host system as is in use on the VM. Laurențiu, what do you think?
It would be technically possible and, as you pointed out, the disk footprint of the current images wouldn't change much.
Our centos/7 image is around two times larger than Fedora Cloud (409MB vs 208MB for the VirtualBox variant). I would like to reduce our image size as soon as 7.4.1708 is released - it would make downloading the image and instantiating a new box significantly faster, as well as reducing our bandwidth usage (we have 4.5 million downloads so far). We have to uninstall some packages that Anaconda insists on always installing, but we don't regain the space used by those packages unless we fill the freed sectors with zeros. On XFS, we can only fill the entire disk with zeros using dd in %post (zerofree only works with Ext4 filesystems, which is what Fedora uses) - writing 40GB of zeros on our CBS builder would already be pretty bad, I wouldn't want to switch to 100-200GB disk images (the disk I/O is actually double that size, since the sparsify process would need to read the image file resulting from the installation).
Adding another disk to a Vagrant box is a somewhat fragile process, but resizing the existing disk image works pretty well and could be automated, I think. [1] You could also use Packer to generate customized versions of our official images for you own use - please see the vbox-packer branch in [2]. The latter is fully automated and takes less than 30 minutes on my Mac Mini "late 2009" with only 4GB RAM and a slow mechanical hard drive.
Best regards, Laurențiu
[1] https://www.laurentiupancescu.com/blog/591c105a/ [2] https://github.com/lpancescu/sig-cloud-instance-build _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 19/08/17 14:22, Richie Rees wrote:
Any change of getting the guest additions installed with the vbox? Have looked at your ft branch and can't see the additions being installed and is a requirement for inclusion on the vagrant forge. I understand that the additions have to be compiled against the kernel, as we require this on my current project is we set up a pipe line to compile the additions against all kernels and drop them in an S3 bucket, you could do a curl at the end of the kick script to obtain the correct additions to match the kernel?
TL;DR Generate your own CentOS images if you really need the Guest Additions.
The Vagrant images generated by the Packer configuration in my vbox-packer branch _do_ include the VirtualBox Guest Additions as part of the image - both centos/6 and centos/7. [1] Clone my repo locally, switch to the vbox-packer branch and run "packer build -only centos-7 packer.json" to generate the images. You might want to replace the German CentOS mirror in packer.json with one closer to you. Another option would be [2], which is a little faster, but it needs Ansible on the host (Windows users might be out of luck).
As for including the VirtualBox Guest Additions in the official images... it's complicated. The build process can only access official CentOS repos, third-party packages are off-limits for security and reproducibility reasons - the builders don't even have Internet access. Not even EPEL packages are an option. VirtualBox isn't packaged by us yet, and my first attempts were blocked by the upstream source not even compiling on CentOS 6.9 (the kernel is too old) and CentOS 7 versions prior to 7.3 (due to a bug in gcc 2.8.5, which is the system compiler for 7.x). CentOS Linux 7.3.1611 is now able to compile the VirtualBox sources, I just haven't found the time to create a regular rpm and a kmod. This would be the right way to do it, and might even allow us to benefit from the stable ABI offered by CentOS kernels to avoid recompiling the Guest Additions during each kernel upgrade. It's a significant amount of work and at the very bottom of my priorities list, but I would certainly look at any .spec files if someone else decides to invest the effort.
I never heard of Vagrant Forge, and a Google search didn't return anything - did you mean Vagrant Cloud (formerly part of Hashicorp's Atlas)? In any case, that "requirement" certainly isn't enforced by Hashicorp: the official Fedora, Debian and Ubuntu images don't include the VirtualBox Guest Additions either, there are weird file corruption issues with the Guest Additions in some situations (we also received a report about kernel panics under high load) and the images work just fine without them (the README in [2] has more details). I'm also not sure if the CentOS Project would be fine with shipping tainted kernels [3] as the default in a set of official images.
Best regards, Laurențiu
[1] https://github.com/lpancescu/sig-cloud-instance-build/blob/vbox-packer/vagra... [2] https://github.com/lpancescu/cloud-instance-starter-kit [3] https://lkml.org/lkml/2011/10/6/317
Laurentiu Pancescu kirjoitti 19.8.2017 klo 9.03:
We have to uninstall some packages that Anaconda insists on always installing, but we don't regain the space used by those packages unless we fill the freed sectors with zeros.
How about:
for pkg in $packages_to_be_removed do rpm -ql $pkg | while read file do if [ -f $file ] then shred -n0 -uz $file fi done done rpm --erase $packages_to_be_removed
This would eliminate the need of having to use dd. Obviously some packages may want to run an uninstallation script at uninstall time, which may (or may not) cause errors if some critical executables have vanished. rpm's --noscripts may help in that case, if running the uninstallation script is not actually necessary.
With the dd step removed, enlarging the file system size should be easier, if desired.
On 19/08/17 15:12, Anssi Johansson wrote:
for pkg in $packages_to_be_removed do rpm -ql $pkg | while read file do if [ -f $file ] then shred -n0 -uz $file fi done done rpm --erase $packages_to_be_removed
This would eliminate the need of having to use dd. Obviously some
packages may want to run an uninstallation script at uninstall time, which may (or may not) cause errors if some critical executables have vanished. rpm's --noscripts may help in that case, if running the uninstallation script is not actually necessary.
Some of these packages might need to be reinstalled after the box is created, either by the user or as dependencies of other packages (e.g. the kernel depends on linux-firmware, but putting the latter in yum's exclude list was ignored by Anaconda - no idea if that would be respected by yum during normal operation, there was no newer kernel when I tested). We might break things by not uninstalling packages the way they were meant to. I think using a hypothetical zerofree for XFS would be the right way to do it (we could switch the Vagrant images back to ext4, but there's some opposition to this due to the fixed number of inodes in ext4).
With the dd step removed, enlarging the file system size should be
easier, if desired.
Indeed. I'd have no objection to the increase in the maximum disk size of the Vagrant images if the dd problem would disappear.
On Sat, Aug 19, 2017 at 12:03 AM, Laurentiu Pancescu < lpancescu@centosproject.org> wrote:
Laurențiu, what do you think?
It would be technically possible and, as you pointed out, the disk footprint of the current images wouldn't change much.
Our centos/7 image is around two times larger than Fedora Cloud (409MB vs 208MB for the VirtualBox variant). I would like to reduce our image size as soon as 7.4.1708 is released - it would make downloading the image and instantiating a new box significantly faster, as well as reducing our bandwidth usage (we have 4.5 million downloads so far). We have to uninstall some packages that Anaconda insists on always installing, but we don't regain the space used by those packages unless we fill the freed sectors with zeros. On XFS, we can only fill the entire disk with zeros using dd in %post (zerofree only works with Ext4 filesystems, which is what Fedora uses) - writing 40GB of zeros on our CBS builder would already be pretty bad, I wouldn't want to switch to 100-200GB disk images (the disk I/O is actually double that size, since the sparsify process would need to read the image file resulting from the installation).
Adding another disk to a Vagrant box is a somewhat fragile process, but resizing the existing disk image works pretty well and could be automated, I think. [1] You could also use Packer to generate customized versions of our official images for you own use - please see the vbox-packer branch in [2]. The latter is fully automated and takes less than 30 minutes on my Mac Mini "late 2009" with only 4GB RAM and a slow mechanical hard drive.
Thanks for the reply and sorry I'm only just now getting back to this. I'd love to figure out the 'dd' issue so we can increase the base box disk size easily.
A few questions as I look at https://github.com/lpancescu/sig-cloud-instance-build
1) I don't see where the 'dd' is happening, could you point to that? 2) Is there a strong reason to use xfs instead of ext4 on the Vagrant VMs? 3) It seems you could shrink down the install size by adjusting the kickstart. Doing i.e. '%packages --nobase', and also removing '@core' and instead adding just the individual desired packages to the list should help reduce the size (and the need to remove stuff after install).
Thanks, Jeff
On 25/08/17 17:28, Jeff Sheltren wrote:
A few questions as I look at https://github.com/lpancescu/sig-cloud-instance-build
- I don't see where the 'dd' is happening, could you point to that?
Not implemented yet in CentOS, but reducing the image size is something I intend to do as soon as 7.4.1708 is released. You can take a look at Fedora's kickstart (no idea why they don't use zerofree, Fedora images only use ext4):
https://pagure.io/fedora-kickstarts/blob/master/f/fedora-cloud-base.ks#_242-...
- Is there a strong reason to use xfs instead of ext4 on the Vagrant VMs?
"Strong" is somewhat subjective, but XFS is the default filesystem in CentOS and some people ran out of inodes with our ext4 Vagrant images, without running out of space. I wanted to go back to ext4 (with a small bytes-per-inode parameter) and get rid of the swap partition, like Fedora Cloud, but there was quite enthusiastic opposition in #centos-devel to moving away from XFS.
- It seems you could shrink down the install size by adjusting the
kickstart. Doing i.e. '%packages --nobase', and also removing '@core' and instead adding just the individual desired packages to the list should help reduce the size (and the need to remove stuff after install).
I know, but... Our official images are quite popular and users seem to prefer an experience close to what you'd get by installing CentOS yourself, so we tend to err on the side of not changing things and not straying too far away from users' expectations. We're still using an IDE controller for the VirtualBox images, even though the VirtualBox docs recommend using SATA or SCSI for performance reasons, again due to vocal opposition to changing the (bad) defaults - mostly from Marcin. I didn't even remove the man pages from the images yet (like Fedora does), and I think users would be confused if @core wouldn't be part of the images. We could also reduce the image size considerably if the CentOS kernels were also split in packages for VMs and for real hardware, like it's been in Fedora for several releases - I'm afraid that's up to Red Hat, though.
I started to go through the XFS documentation, to see if it's possible to implement something similar to zerofree. I'm quite tired during the week after work and commuting (there are constant traffic jams around Stuttgart - think 35km one-way in 60-90 minutes), so progress is really slow.
Best regards, Laurențiu
On Sat, Aug 26, 2017 at 2:18 AM, Laurentiu Pancescu lpancescu@centosproject.org wrote:
On 25/08/17 17:28, Jeff Sheltren wrote:
A few questions as I look at https://github.com/lpancescu/sig-cloud-instance-build
- I don't see where the 'dd' is happening, could you point to that?
Not implemented yet in CentOS, but reducing the image size is something I intend to do as soon as 7.4.1708 is released. You can take a look at Fedora's kickstart (no idea why they don't use zerofree, Fedora images only use ext4):
https://pagure.io/fedora-kickstarts/blob/master/f/fedora-cloud-base.ks#_242-...
Stop *right here*. OK, I went through pretty much this fun and games around 2001 working for Honking Big Proxy Service(tm). You're really going to hurt yourself trying to pre-optimize your disk images and shove them into a pre-allocated filesystem. Come listen to a story from an old timer.
In those days of yore, with Red Hat 5.2, (not RHEL 5.2, Red Hat 5.2), an engineer thought much the way you did. "Build a complete disk image, but you have to 'dd' it to compress it and make it small enough, and we have different disk images, so we have to use 'dd' to fill it with zeroes and make it compress, so we need to do this one for each image and carry multiple images one for each disk size"
You will hurt yourself doing this. Work from a tarball, *not-not-not* a disk image, built on a chroot cage. Apply modifications as needed. Compress *that* into a new tarball. Use the kickstart '%pre" tools to build your new file system, of whateve the !@#$ file you want, in a *much* faster and more flexible procedure than anything you can do from a disk image. Untar your contents into *that*, run a boot loader tool from inside the disk image built to whatever environment you want, and let kickstart procedures run on *that* at install time as needed to actually finish configuring the sytem.
With sensibly written %pre and %post steps, you can *skip* most of the anaconda procedures and do whatever the heck you want with the available disk space, including setting up as small as feasible of a bootable disk and slapping the tarball onto it.
- Is there a strong reason to use xfs instead of ext4 on the Vagrant VMs?
"Strong" is somewhat subjective, but XFS is the default filesystem in CentOS and some people ran out of inodes with our ext4 Vagrant images, without running out of space. I wanted to go back to ext4 (with a small bytes-per-inode parameter) and get rid of the swap partition, like Fedora Cloud, but there was quite enthusiastic opposition in #centos-devel to moving away from XFS.
xfs is the standard for CentOS 7, not CentOS 6. For virtual purposes, it does support dynamic expansion of disks and partitions much more effectively than the "/" partition can be supported under ext4. I'd recommend it for that reason alone for such use, despite some personal confidence in the author of ext2, etc. (Ask privately if you're curious: I've known the boy a while.)
I started to go through the XFS documentation, to see if it's possible to implement something similar to zerofree. I'm quite tired during the week after work and commuting (there are constant traffic jams around Stuttgart - think 35km one-way in 60-90 minutes), so progress is really slow.
Brother, you've my sympathies. I set up for a while working in London spending weekends with my family, and staying at a cheap flatshare in Elephant and Castle. I was very productive, though it was rough on me and my family. I wound up buying every Robin Hobb book I could find for the 2 hour train commutes, and spent a fascinating month in Portsmouth one night due to dangerous hypoglycemia and a missed transfer. It got much better after 4:00 AM when I found the only all-night diner available and met very nice night people to chat up. Being the only native English speaker on a London bus at 2:00 AM was a frequent and fascinating experience.
On 27/08/17 04:45, Nico Kadel-Garcia wrote:
On Sat, Aug 26, 2017 at 2:18 AM, Laurentiu Pancescu lpancescu@centosproject.org wrote: Stop *right here*. OK, I went through pretty much this fun and games around 2001 working for Honking Big Proxy Service(tm). You're really going to hurt yourself trying to pre-optimize your disk images and shove them into a pre-allocated filesystem. Come listen to a story from an old timer.
You will hurt yourself doing this. Work from a tarball, *not-not-not* a disk image, built on a chroot cage. Apply modifications as needed.
Expanding a tarball on an empty image sounds much better than filesystem-dependent tricks to eliminate allocated, but unused, blocks. I saw a few months ago that Scaleway uses Docker to generate CentOS images for their physical servers (which boot without Docker) and are debuggable as Docker images as well, but they seem quite broken when I look at the open issues: problems with yum update, SELinux is disabled and enabling it doesn't work, mounting the wrong root filesystem, LVM not mounting volumes on boot... so I thought I'd rather not go that route. Perhaps simply copying the files from another image, generated by Anaconda, and running grub inside the copy would work, though.
https://github.com/scaleway/image-centos
I started to go through the XFS documentation, to see if it's possible to implement something similar to zerofree. I'm quite tired during the week after work and commuting (there are constant traffic jams around Stuttgart - think 35km one-way in 60-90 minutes), so progress is really slow.
Brother, you've my sympathies. I set up for a while working in London spending weekends with my family, and staying at a cheap flatshare in Elephant and Castle. I was very productive, though it was rough on me and my family. I wound up buying every Robin Hobb book I could find for the 2 hour train commutes, and spent a fascinating month in Portsmouth one night due to dangerous hypoglycemia and a missed transfer. It got much better after 4:00 AM when I found the only all-night diner available and met very nice night people to chat up. Being the only native English speaker on a London bus at 2:00 AM was a frequent and fascinating experience.
Ouch - and I thought I had it tough, commuting in my car in the sun at 35C outside (I love manual transmission, which is pretty much the norm here, but constantly pressing and releasing the clutch during traffic jams for around an hour every day is no fun for my knee, and I'm not getting any younger). I should probably move closer to work, as soon as possible.
Best regards, Laurențiu
Hi Laurentiu, have you had a chance to look at the xfs issue around zerofree?
On Sat, Aug 26, 2017 at 12:18 AM, Laurentiu Pancescu < lpancescu@centosproject.org> wrote:
- Is there a strong reason to use xfs instead of ext4 on the Vagrant VMs?
"Strong" is somewhat subjective, but XFS is the default filesystem in CentOS and some people ran out of inodes with our ext4 Vagrant images, without running out of space. I wanted to go back to ext4 (with a small bytes-per-inode parameter) and get rid of the swap partition, like Fedora Cloud, but there was quite enthusiastic opposition in #centos-devel to moving away from XFS.
Anyone reading this thread opposed to using ext4 on the Vagrant images and care to share your concerns? From my perspective, the entire purpose of Vagrant is to provide a (reproducible) development environment for application developers that shouldn't be concerned with the filesystem in use outside of some edge cases. If ext4 gives an easier way to shrink the image size, and it sounds like it does, why not use that by default here?
- It seems you could shrink down the install size by adjusting the
kickstart. Doing i.e. '%packages --nobase', and also removing '@core' and instead adding just the individual desired packages to the list should help reduce the size (and the need to remove stuff after install).
I know, but... Our official images are quite popular and users seem to prefer an experience close to what you'd get by installing CentOS yourself, so we tend to err on the side of not changing things and not straying too far away from users' expectations. We're still using an IDE controller for the VirtualBox images, even though the VirtualBox docs recommend using SATA or SCSI for performance reasons, again due to vocal opposition to changing the (bad) defaults - mostly from Marcin.
Is it possible and worth creating a "7-minimal" vagrant image in addition to the default one currently built? For my needs, minimal (with a larger partition!) would be perfect because I just want a small, standard CentOS image that can then be configured with whatever config management system to prep it for development.
-Jeff
On Tue, Sep 12, 2017 at 8:51 PM, Jeff Sheltren jeff@tag1consulting.com wrote:
Hi Laurentiu, have you had a chance to look at the xfs issue around zerofree?
On Sat, Aug 26, 2017 at 12:18 AM, Laurentiu Pancescu < lpancescu@centosproject.org> wrote:
- Is there a strong reason to use xfs instead of ext4 on the Vagrant VMs?
"Strong" is somewhat subjective, but XFS is the default filesystem in CentOS and some people ran out of inodes with our ext4 Vagrant images, without running out of space. I wanted to go back to ext4 (with a small bytes-per-inode parameter) and get rid of the swap partition, like Fedora Cloud, but there was quite enthusiastic opposition in #centos-devel to moving away from XFS.
Anyone reading this thread opposed to using ext4 on the Vagrant images and care to share your concerns? From my perspective, the entire purpose of Vagrant is to provide a (reproducible) development environment for application developers that shouldn't be concerned with the filesystem in use outside of some edge cases. If ext4 gives an easier way to shrink the image size, and it sounds like it does, why not use that by default here?
- It seems you could shrink down the install size by adjusting the
kickstart. Doing i.e. '%packages --nobase', and also removing '@core' and instead adding just the individual desired packages to the list should help reduce the size (and the need to remove stuff after install).
I know, but... Our official images are quite popular and users seem to prefer an experience close to what you'd get by installing CentOS yourself, so we tend to err on the side of not changing things and not straying too far away from users' expectations. We're still using an IDE controller for the VirtualBox images, even though the VirtualBox docs recommend using SATA or SCSI for performance reasons, again due to vocal opposition to changing the (bad) defaults - mostly from Marcin.
I'm not opposing changes to the controllers, only the random behavior of the centos/7 image depending on the version of virtualbox: https://www.virtualbox.org/ticket/16387
Marcin
Is it possible and worth creating a "7-minimal" vagrant image in addition to the default one currently built? For my needs, minimal (with a larger partition!) would be perfect because I just want a small, standard CentOS image that can then be configured with whatever config management system to prep it for development.
-Jeff
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 12/09/17 21:33, Marcin Dulak wrote:
I'm not opposing changes to the controllers, only the random behavior of the centos/7 image depending on the version of virtualbox: https://www.virtualbox.org/ticket/16387
Nice to hear that. The IDE images default to using the host caching system, which wastes host memory to cache things cached by the guest anyway (that decreases the host performance, especially if youțre not using it exclusively for running VMs). Things like NCQ offered by SATA but not IDE increase the performance even more.
FWIW, I've seen the "IDE" vs "IDE Controller" issue even with the same release of VirtualBox, by instantiating a box several times. I assume it's a bug in VirtualBox that our particular config file happens to trigger. Perhaps we could rebase the config file in ImageFactory on what VirtualBox generates, but that would be Ian's decision.
Regards, Laurențiu
On 12/09/17 20:51, Jeff Sheltren wrote:
Hi Laurentiu, have you had a chance to look at the xfs issue around zerofree?
I'm sometimes too tired to do much besides dropping to bed (I wake up at 6AM and only manage to arrive home between 20-21). I haven't finished the XFS documentation yet. :(
Is it possible and worth creating a "7-minimal" vagrant image in addition to the default one currently built? For my needs, minimal (with a larger partition!) would be perfect because I just want a small, standard CentOS image that can then be configured with whatever config management system to prep it for development.
May I ask why creating your own image with my Packer script isn't an option? It would closely follow our image (I merge the changes from the official images when necessary). You could upload it to Vagrant Cloud to have available for the rest of your team and your customers.
Regards, Laurențiu
On Tue, Sep 12, 2017 at 2:42 PM, Laurentiu Pancescu < lpancescu@centosproject.org> wrote:
On 12/09/17 20:51, Jeff Sheltren wrote:
Hi Laurentiu, have you had a chance to look at the xfs issue around zerofree?
I'm sometimes too tired to do much besides dropping to bed (I wake up at 6AM and only manage to arrive home between 20-21). I haven't finished the XFS documentation yet. :(
No problem, IMO the switch to ext4 makes more sense anyway, but let's see what others think.
Is it possible and worth creating a "7-minimal" vagrant image in addition
to the default one currently built? For my needs, minimal (with a larger partition!) would be perfect because I just want a small, standard CentOS image that can then be configured with whatever config management system to prep it for development.
May I ask why creating your own image with my Packer script isn't an option? It would closely follow our image (I merge the changes from the official images when necessary). You could upload it to Vagrant Cloud to have available for the rest of your team and your customers.
That's possible -- and we've built our own custom boxes in the past -- but it's additional work to build each time there's an upstream release. If I were to go this route only to increase the disk image size, I'd consider building a customized image per-client instead (with puppet pre-run), and that's what I'm trying to get away from. For the most part we've been happy with your Vagrant image, we're just hitting these disk size issues for some clients with large data sets.
Thanks, Jeff
-
Anssi Johansson -
Jeff Sheltren -
Karanbir Singh -
Laurentiu Pancescu -
Marcin Dulak -
Nico Kadel-Garcia -
Pavel Valena -
Richie Rees