[Container-tools] Subtlety with libvirt provider that is causing quite a bit of misinformation

Dusty Mabe dusty at dustymabe.com
Thu Jun 2 14:25:55 UTC 2016



On 06/02/2016 10:23 AM, Dusty Mabe wrote:
> 
> There is a small subtlety with the libvirt vagrant provider that many
> people aren't aware of.
> 
> On the first `vagrant up` the vagrant box will be uploaded to the
> libvirt storage pool and then used as a backing device for the vm that
> gets started. So now you have the vagrant box file (lives in the
> .vagrant.d directory) as well as a file in the libvirt storage pool.
> 
> The problem comes about when you remove/re-add a box to a machine.
> When you remove the box, it removes the box from vagrant but it does
> not remove the box from the libvirt storage pool. If you subsequently
> re-add the box (a newer version this time) to vagrant and perform a
> `vagrant up` then no box gets uploaded because there is already a 
> "backing image" in libvirt with that name.
> 
> What this leads to is people thinking they have the latest version of
> the CDK installed, but really using something that is old as dirt.
> 
> One example of this was the developers post [1] that came out a week
> ago. The author was using a CDK box from January and some of the
> information he had in the post was old.
> 
> Another example came to me from some of my contacts in consulting. 
> 
> Basically this is dangerous because some people can "test" things and
> "verify" they are working and not realize they are using old stuff.
> 
> We need to somehow resolve this in the vagrant-libvirt provider or 
> come up with some other, client side way of verifying things.
> 
> Dusty
> 
> [1] http://developers.redhat.com/blog/2016/05/27/use-vagrant-landrush-to-add-dns-features-to-your-openshift-cdk-machine/


You can workaround this now by doing something like the following:

vagrant box remove cdkv2
virsh vol-delete --pool default cdkv2_vagrant_box_image_0.img
vagrant box add ...

Dusty




More information about the Container-tools mailing list