On Mon, Oct 20, 2014 at 7:12 AM, Kristian Nielsen
Otto Kekäläinen writes:
There is no need for this image to be so big. The OS is maybe that 3.1 GB and the MariaDB build output is about 3 GB, so something like 9 GB disk size should be well enough by a fair margin.
Right. On the other hand, there is a lot of work involved in re-doing the VM images in case of too-small image, so I can understand Daniel's reasons for making the images "large enough". This is just the maximum size, the actual size will be no bigger than what is actually used.
However, with a large max size, we still need to disable the ramdisk usage. Because in case a lot of space is used, this can cause failures in other, unrelated builds due to disk full.
I don't know that the ramdisk optimisation is that important anyway, so it seems reasonable to just disable it here.
+ qemu-img create -b /kvm/vms/vm-centos7_0-x86_64-build.qcow2 -f qcow2 /dev/shm/vm-tmp-2302.qcow2 qemu-img: '' uses a qcow2 feature which is not supported by this qemu version: QCOW version 3 qemu-img: Could not open '/kvm/vms/vm-centos7_0-x86_64-build.qcow2' Failed to clone base image, aborting
For now, I updated the Buildbot config to not use the terrier buildslave for this builder. If any more images are made with the newer file version, the associated builders need to be similarly disabled, using this option:
slaves=kvm11_slaves
I think it was just the CentOS7 VMs that were created such that they aren't compatible with the older qcow2 format. When I made the opensuse VMs, for example, I made sure they used the old qcow2 format. That said, I think we really need to rebuild terrier, to get it up-to-date, install a larger hard disk, and generally get it more in step with bb01 and bb02, but that's a different discussion.
Also, another issue related to VM images. Our old images were created with rather small disk size. I noticed that some new images are created much larger, for example:
I will try to fix the config to not use ramdisk for existing images that have too large virtual size. But it is something to keep in mind for the future.
So now I added an option ramdisk=True|False to getDebBuilder() and similar functions. And I checked all images, and added ramdisk=False for all those builders that I found used some of the images with large maximum size.
Any further image made with large max size should then also use the ramdisk=False option.
An alternative method to having big VM max size is to do like getFullTest() does. It adds an extra blank disk image that is not put in ramdisk:
args = args + ["--kvm=-hdb", "--kvm=vm-blank-20G.qcow2"]
and then mounts and uses it inside the VM.
But again, if the ramdisk optimisation is not needed on the newer/better buildbot machines, there might be little need for this extra complexity.
Thanks! This solution works for me. -- Daniel Bartholomew, MariaDB Release Manager MariaDB | http://mariadb.com