On 21 September 2012 21:58, Henrik Ahlgren <pablo@xxxxxxxxxxxxx> wrote:
The KVM agents host Atlassian Bamboo build agents (http://www.atlassian.com/software/bamboo/overview).
I want them to run continuously and be ready to be used for builds but:
1. I can take them down for maintenance any time between builds.
2. They are disposable (i.e. loosing them for disk crash is NOT a catastrophe), so I want maximum speed even on expense of less (or actually no) redundancy.
The only way to update their software that I could think of so far is to rebuild the base image on the KVM host and reboot the KVM guests from the new image next time they become idle.
Have you got other ideas?
Thanks for the suggestion.
I am not interested in saving disk space, I have enough of it. The main motivation for this exercise the potential speed-up from having some disk blocks read once then shared by all the KVM agents in memory.
About KSM - my understanding is that it doesn't come free (the KVM's have to madvise(2) about candidate memory pages, and the kernel still has to scan the memory to find them) and I assume that I can remove the need for KSM since I can already tell that the disk images are identical, so why let the kernel try to find the identical pages?
Cheers,
--Amos
--
![View my profile on LinkedIn]()
On Fri, Sep 21, 2012 at 09:22:24PM +1000, Amos Shapira wrote:
> 2. Maintenance - if I get to share the common disk image among all of themHow do you plan on upgrading the read-only VMs after the initial
> then I only need to install/update it once instead of once for each KVM
> guest (we already use Puppet but it doesn't mean it comes for free).
installation, or are they short-lived and frequently recreated from
scratch using a fresh image? Read-only, shared /usr between machines
is a nice idea in theory, but at least the modern linux distros'
package management tend not to support it that well in practice.
The KVM agents host Atlassian Bamboo build agents (http://www.atlassian.com/software/bamboo/overview).
I want them to run continuously and be ready to be used for builds but:
1. I can take them down for maintenance any time between builds.
2. They are disposable (i.e. loosing them for disk crash is NOT a catastrophe), so I want maximum speed even on expense of less (or actually no) redundancy.
The only way to update their software that I could think of so far is to rebuild the base image on the KVM host and reboot the KVM guests from the new image next time they become idle.
Have you got other ideas?
IMHO using a QCOW2 backing files as base templates works pretty well
and gives you similar disk space savings, at least initially. And
KSM does the same with RAM.
Thanks for the suggestion.
I am not interested in saving disk space, I have enough of it. The main motivation for this exercise the potential speed-up from having some disk blocks read once then shared by all the KVM agents in memory.
About KSM - my understanding is that it doesn't come free (the KVM's have to madvise(2) about candidate memory pages, and the kernel still has to scan the memory to find them) and I assume that I can remove the need for KSM since I can already tell that the disk images are identical, so why let the kernel try to find the identical pages?
Cheers,
--Amos
--
_______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
