I'm not a vagrant user, but your question intrigued me. A quick skim of the documentation for the vagrant-libvirt module shows a synced folders section[0], which appears to support configs for NFS and 9pfs for two-way sync. Do those not work? I use vanilla libvirt, and I've had great luck with exposing my development directories to VMs using the 9pfs resource sharing. If the vagrant plugin isn't doing that, then it may just be a small bug in the libvirt XML file they're generating. Or am I totally off-base?
Thanks, I'll look into it more closely. I tried the libvirt module and I remember having issues with it. I don't remember if there were no compatible debian boxes for it, or it didn't work properly on windows... something was there.
I see this as a vagrant issue though. It really falls short of its promise of being a dev environment where you "never say 'it works on my machine' again".
why can't you do it in the user space within those VM's, communicating over a network adapter? If you don't care about putting on a raincoat, going outside to the Internet, and launching it up into the cloud, you can just install dropbox and get a sync'd directory without additional work. Obviously this is extra unnecessary overhead, two times, but for your use case you may not care.
you can alternatively roll your own solution though it might take you an hour or two. think about rsync over a local network adapter.
I realize these are hackish solutions but if it's stupid but it works, it's not stupid.
on the plus side you will control that traffic. having directory syncing that breaks the VM abstraction opens leaks due to potential oversights in how it's coded.
if I were in your predicament I would work around it.
Bidirectional syncing primary use case is for development. Requiring a bunch of hacks and overhead is a terrible idea and controlling the traffic is not a useful feature for that use case.
I understand that, but it's not reasonable to ask that the VM intrusively modify the filesystem without the guest operating system knowing about it: therefore the "correct" solution is some guest userspace utilities for the user to install, which perform these operations from inside the VM. (If a 5 in a file changes to a 6, then rather this change happening from outside the VM, to the total surprise of the guest OS, as though you pulled the hard drive, mounted it in another computer, modified that one value, and remounted it in the original computer, all without the guest OS even being aware that the hard drive had been unmounted or modified, instead, it should be performed by a utility from inside the VM.)
The difference between this proper approach, and what you call "hacks" is minimal, and basically a question of packaging. To be clear, I agree that the VM developer should write and package these utilities for every major guest operating system it supports.
[0] https://github.com/vagrant-libvirt/vagrant-libvirt#synced-fo...