[HN Gopher] Keep your files inside your VM
___________________________________________________________________
Keep your files inside your VM
Author : exec1
Score : 18 points
Date : 2023-08-31 20:29 UTC (2 hours ago)
(HTM) web link (msimkunas.lt)
(TXT) w3m dump (msimkunas.lt)
| miller_joe wrote:
| I've been experimenting with working in a gcp VM for a few months
| and like it quite a bit. Between ssh+tmux+nvim and vscode-remote
| I have a remote and local dev exp that is basically identical.
|
| Syncthing is my key to keeping my ~/git tree in sync between the
| two environments. Just have to be careful not to try to flip back
| and forth quickly between local/remote as syncthing delays can be
| ~10s.
| aaplok wrote:
| > Syncthing is my key to keeping my ~/git tree in sync between
| the two environments.
|
| Why don't you use git directly for that?
| johnmaguire wrote:
| I assume to avoid commit spam.
| lgvld wrote:
| I always had trouble when using Syncthing for .git folders:
| they usually end up corrupted / messed up if I push on both the
| local and remote .git folders.
| skydhash wrote:
| Mutagen is great for syncing. It's very fast and painless to
| setup.
| nneonneo wrote:
| I've used a VMWare Fusion shared folder between a Mac host and
| Linux/Windows guests for several years with zero issues.
| Performance has generally been very good, basic permissions work
| (haven't needed anything beyond rwx), and I gain the ability to
| pretty freely move between host and guest with ease. For example,
| my Linux guest is headless, so I do most of my editing in a GUI
| editor or IDE on the Mac side on shared files.
|
| I also have some little quality-of-life scripts on the Linux side
| for things like editing shared files in the Mac editor, opening
| shared folders in Finder, etc. These make it a fairly seamless
| experience to go back and forth between the two OSes.
| exec1 wrote:
| Depends on your requirements, I guess. I wanted a solution that
| would allow me to work with Linux ACLs and symlinks as well as
| get me the best possible performance so going native was
| basically the only choice. I started from this and then
| basically just worked around this premise. The only
| alternatives here were 2 - file syncing or sharing a directory
| with the host.
| rwmj wrote:
| virtio-fs (https://virtio-fs.gitlab.io/) is a more modern option
| for sharing files between host and guest. Also if the VM is
| offline and you need to pull files on or off, then guestfish
| (https://libguestfs.org/guestfish.1.html).
| exec1 wrote:
| I didn't know about Guestfish, thanks for the reference!
|
| Yes, virtio-fs is an option but I should have added that one of
| my goals was to not lock myself into a platform... I want to
| have the possibility of running my VMs on Windows as well and
| Samba seems like the easiest choice there. Just spin up a Samba
| share inside the VM, mount it on the Windows host and you're
| good to go. No need to install any additional dependencies on
| the host.
|
| I've tried the Windows NFS driver for Vagrant a while back and
| my conclusion is that it's best not to force a square peg into
| a round hole... Not to mention that these custom solutions can
| experience software rot throughout the years.
| predictabl3 wrote:
| Hard to trust this when the conclusion is to use NFS instead of
| VirtioFS. I don't buy that NFS over network, to a VM is faster
| than 9p, and certainly isn't faster than VirtioFS. Though "share
| from the VM" is good advice for NFS, since you can just reboot
| the guest when some part of NFS inevitably hangs (not-so-distant
| trauma here, including learning how to force power-off when
| shutdown is broken by NFS).
|
| And yes, it works with Windows: https://virtio-
| fs.gitlab.io/howto-windows.html
| exec1 wrote:
| The point I was trying to make in the article was more about
| reversing the direction of mounts so that instead of mounting a
| host directory on the guest you share a directory from the
| guest and mount it with a client on the host. You can achieve
| this using whatever - NFS, Samba, etc. This is obviously not a
| new concept but I find it astonishing that perhaps the majority
| of articles on the internet always talk about mounting a host
| directory on the guest which is problematic due to the reasons
| I covered in my article.
|
| The main advantage of this approach is that your code resides
| on a native file system. This allows you to take advantage of
| this performance gain where it matters most, which for me is
| during runtime (I develop web applications and IO performance
| is of paramount importance). I care much, much less about
| performance on the host side.
| exec1 wrote:
| Also, regarding VirtioFS: this is indeed something I have not
| yet tried. I'm wary of this though because this requires
| installing additional drivers on Windows and I usually prefer
| using tools that are already at my disposal (e.g. Samba on
| Windows).
| gomoboo wrote:
| I use PyCharm+Vagrant in my day job. Bidirectional syncing comes
| by default there and has been pretty seamless. I don't usually
| need to create files in the VM but when I do having them appear
| on the host for inspection is great. I also haven't noticed any
| performance issues with the setup compared to developing solely
| on the host.
| exec1 wrote:
| Are you referring to bidirectional syncing built into Jetbrains
| IDEs? If so, I have mixed feelings about it.
|
| I gave this setup a go with PhpStorm. Host-to-VM sync is pretty
| seamless but you always have to manually sync changes from the
| guest to the host, so there's that. Additionally, syncing can
| be very slow on large directory trees. I often found myself
| staring at a loading animation waiting for the IDE to catch all
| the changes and sync them to the guest.
|
| AFAIK it is not recommended to open a project located on a
| network drive in a Jetbrains IDE but my experience with it so
| far has been great. Latency is not a concern because the VM is
| local.
|
| Most importantly, I wanted to avoid a syncing situation where
| you have the source and the destination with two possibly
| differing states. This difference implies the possibility of
| conflicts which complicates things even further.
| YarickR2 wrote:
| So, basically: performance accessing files on the host from the
| VM over NFS is not great, and this is bad. performance accessing
| files in the VM from the host over NFS is not great, and this is
| ok . Kind of self-contradictory
| Zambyte wrote:
| I mainly use GNU, but sometimes I develop with a VM running
| Windows. I mainly live inside Emacs. A nice way to access my
| Windows system is through TRAMP, which (T)ransparently extends
| the filesystem at an application level over various protocols. I
| have found that using Emacs as a Samba client to access Windows
| works quite well for me.
|
| Unfortunately recent versions of Samba makes it hard
| (impossible?) to spawn remote processes; else I would be able to
| use eshell inside Emacs, which is pretty awesome over SSH.
| hsbauauvhabzb wrote:
| I doubt the latest assertion, the impacket tooling is well
| known for executing code over various interfaces. I have no
| idea how it works, but I imagine it would be difficult to
| truely prevent exec over smb.
|
| Fwiw though, windows now supports openssh via a powershell
| command to install (e.g it's not some third party binary). I'm
| not sure if it supports sftp, but it may be worth looking into.
| Zambyte wrote:
| I'll have to give execing over smb another look.
|
| I did try using OpenSSH, but there were issues with using
| Powershell through eshell over TRAMP. It expects a POSIX
| shell. I also tried using Cygwin to run OpenSSH, but that
| didn't work well for my needs.
| exec1 wrote:
| Is TRAMP similar to SSHFS?
| sgt wrote:
| [flagged]
___________________________________________________________________
(page generated 2023-08-31 23:01 UTC)