d20b48bd96
Tests were seen to time-out on libvirt when raw images were used, which was due to large disk images being copied around inefficiently. A system with standard disks was seen to take an extra 60s/10G which was a problem with large root and ephemeral disks. The changes below attempt to minimize the I/O in dealing with cached raw images. These changes should also help to minimize the disk space used for such images, by avoiding the naïve copy which undoes the sparseness. * nova/virt/libvirt/connection.py (_cache_image): Do the resize here, rather than in _fetch_image(), so that we can control when the resizing is done, to minimize the amount of data that needs to be copied. Also if we're generating rather than fetching the image, then just generate in the instance dir too, as this should be faster. * nova/tests/fake_libvirt_utils.py: Remove the resize functionality since it's no longer used. * nova/tests/test_libvirt.py: Likewise. * nova/virt/libvirt/utils.py (fetch_image): Likewise. (copy_image): Shell out to cp since it deals better with sparse files. Note the above changes avoid sparse copies, so this is just an ancillary improvement in the area. Change-Id: I678d125c61aab56c62c668559eb2220d56702952
The Choose Your Own Adventure README for Nova
You have come across a cloud computing fabric controller. It has identified itself as "Nova." It is apparent that it maintains compatibility with the popular Amazon EC2 and S3 APIs.
To monitor it from a distance: follow @openstack on twitter.
To tame it for use in your own cloud: read http://docs.openstack.org
To study its anatomy: read http://nova.openstack.org
To dissect it in detail: visit http://github.com/openstack/nova
To taunt it with its weaknesses: use http://bugs.launchpad.net/nova
To watch it: http://jenkins.openstack.org
To hack at it: read HACKING
To cry over its pylint problems: http://jenkins.openstack.org/job/nova-pylint/violations