On Mon, Oct 20, 2014 at 7:12 AM, Kristian Nielsen <[email protected]> wrote: > 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 _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
