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

[Dusty Mabe]

On 06/02/2016 11:25 AM, Jason Brooks wrote:
> On Thu, Jun 2, 2016 at 7:23 AM, Dusty Mabe <dusty at dustymabe.com> 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.
> 
> Here's what to watch for:
> 
> $ vagrant box remove centos/atomic-host
> Removing box 'centos/atomic-host' (v7.20160331) with provider 'libvirt'...
> Vagrant-libvirt plugin removed box only from you LOCAL
> ~/.vagrant/boxes directory
>>From libvirt storage pool you have to delete image manually(virsh,
> virt-manager or by any other tool)
> 
> If you see that message, you need to do what it says.
> 
> "vagrant box update" works fine, but is this not an option for the CDK?
> 

Since the CDK doesn't use atlas, it can't use versioning, which I
think means that we can't use `vagrant box update`.

If we could use versioning, the version gets stored alongside the name
of the file in the libvirt storage pool, so this would be less of a
problem.

Dusty