Brian Pitts

Yes, getting feedback from vagrant developers may be a good idea.

I haven't checked into how we would do it, but perhaps we could hook into `vagrant box remove` and when it's removing a libvirt box print a warning about this....

I like the idea, but I'm leery of doing it by default. I think a lot of people using vagrant for testing frequently run `vagrant destroy` followed by `vagrant up`....

To throw out a half-baked idea: Since what seems to bite people is unexpectedly using an outdated box, I wonder if we could find a way to check if the...

@purpleidea I'm hesitant to go around libvirt and work directly on the filesystem, because then we don't have any safeguards preventing us from removing the base box if there are...

@lelutin the problem is knowing where to clean up. When you run `vagrant box add` the box is placed in `~/.vagrant.d/boxes`. Later you run `vagrant up` in the context of...

Only after writing the above does it occur to me, why does a Vagrantfile have to be the only place where information about how to connect to libvirt is stored?...

@aspiers your second idea is interesting. Would we pull all of the provider options (driver, host, etc) from the Vagrantfile and store them in `hosts.d` instead? When running `vagrant up`,...

@aspiers sounds like we have the same understanding of how your proposal would work. Yes, we can [add new subcommands](https://docs.vagrantup.com/v2/plugins/commands.html). Both my idea and @aspiers refinement are a bigger project...

> Extend vagrant box add/remove with a --host option which can reference any file in that directory but defaults to localhost Related to this, I am intrigued by the possibility...