I'm developing for a Linux-based embedded system, where I have a build process from hell, at least to generate a full flashable binary -- tons of dependencies, proprietary compiler, etc. To make development setup easier for new developers, and uniform across our development team, I've adopted Vagrant. But, there's a snag...
So Vagrant spins up a VM and provisions it with our dependencies and tools. Then it mounts the source tree on the host within /vagrant on the VM. However, we cannot build within this directory -- mounts between the host and the VM do not support mmap (at least not in Virtualbox), which the build relies upon. With our developers that run OS X, things are even worse as their host OS is HFS+, case-insensitive out of the box -- the build requires a case-sensitive FS. So developers are forced to work within the VM, which is constraining if you're used to particular development tools in OS X say, and simply want to use the terminal for compilation.
Seems what's needed is a real-time (e.g. inotify based?) bi-directional sync mechanism that would keep /vagrant in sync with say /home/vagrant, which is not a mount point but simply part of the VM's ext4 fs, so produced/edited files and symlinks are synced. Is there such a mechanism? Closest thing I've found is aufs, but I'm not sure that does what we want.
I ended up using NFS (included within Vagrant and OS X) and it's been working well for a couple months now.
Related
When reading the WSL documentation, it is stated that:
"Unlike our practice with trying to exclusively install programs and software on Ubuntu, our files and folders need to live exclusively on the Windows FS [...] Windows and Windows Apps can only read and write Windows files, and VSCode will be making our changes."
I understand the reasoning behind this and indeed, if one uses VSCode for example, it all makes sense. But my question is:
Is there any real reason why you couldn't keep your files (i.e. scripts) on the WSL filesystem itself? More specifically, if you don't ever intend to use the Windows filesystem (i.e you won't ever need a GUI or else), is there any sense in placing the files in the Windows FS?
Obviously you need to make sure you backup your data (GitHub or else) but aside from that, is there any downside? I guess what I'm saying is: can I use WSL like a VM? Can I keep BOTH software AND scripts all in WSL, separate from the Windows filesystem?
PS: The reason for avoiding a VM in this context is because I have a low spec laptop which has struggled a lot in the past with VMs (slow, not enough RAM), and so far, WSL seems be running much more smoothly.
Thanks
The simple answer is yes, you can use WSL as if it were a VM. WSL is for the most part fully-fledged Linux, and you can use Linux as your primary operating system, ignoring the fact you need to start it from within Windows. I haven't tried WSL 2, but it's said to be implemented as a fast VM, which is exactly what you ask for. (Further, the lack of GUIs can be mitigated using built in support for sending X data over SSH to the Windows half of your computer, and display it with an X Server. If I remember correctly, these two articles got me most of my way there.)
However, if you want to get pedantic, you can't store any files separate from your Windows filesystem on WSL 1. If you run e.g. Ubuntu, your Linux filesystem is instead always contained within %USERPROFILE%\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc\LocalState, so it'll technically not be separate. I can't test WSL 2, but according to this article, WSL 2 also stores its data in that folder, just as a single VDHX image. Presumably every WSL distro stores its data on the Windows filesystem.
Warning: Do not access the files themselves in your Linux filesystem within AppData using Windows tools, or you run a high risk of corrupting those files.
Yes, you can, and only place files in the Windows filesystem if you want to share them with Windows programs. Moreover, in Windows 1903 you don't need to place files in Windows filesystem to share them with Windows Programs, they can access them.
In WSL2 they encourage you to keep everything in WSL filesystem to take advantage of the filesystem's performance improve.
So, yes you can and you should.
I have been reading up on docker, and I have understood that unlike VMs, docker uses the host OS's kernel. Why is there a requirement that the base image has to be an OS. Why can't docker use resources from the host OS (eg: filesystem) and use the isolation supported by the host OS ? (I am assuming that the host OS provides mechanism for isolation)
It depends on how you define an OS. Docker images are not full OS (unlike VMs). They do not have a kernel of their own. This means no specific kernel modules (device drivers for external hardware etc) are installed as the host OS already has them.
Images are simply filesystem clones of popular Linux distributions (the binaries in image are offcourse built for the target arch). There can be multiple reasons for it, I would try and put some here:
Near-VM like experience as users like to use their favorite Linux
distribution
Pre-configured libraries based on distribution. Lets you run apps straight away with all distribution-based dependencies taken care.
Flexibility of running multiple distributions on same host (Great dev/test sandboxing!)
Greater isolation from other containers as each image is self sufficient and doesn't have to share a filesystem with others
As part of my infrastructure I have many Virtual Machines running different Linux distros, under Proxmox using OpenVz. My problem is that I need to export into a personalized installable ISOs some of the VMs I have, (installable snapshots of the current state of the VMs), some of them are running Ubuntu, some of them CentOS, so my question is:
1- Is there a way I can do this aware of the OS the VM is running?,
2- Exporting VMs to ISOs the way I just explained is the way to go or is there any other approach?
I'm open to any advice from those how has experience with this subject even if I have to setup different Virt. Technology to host the VMs.
Your question is pretty vague on your requirements. I'll try to give you some ideas:
What do you mean by "Current state"? If you really want all the running processes, then you should something like VirtualBox and take a snapshot. You can easily boot that up on another computer and continue running where you left off, and it's independent of the OS.
If you really mean just the filesystem, then just copying the filesystem and burning it on a CD is unlikely to give you good results. For instance, there are many areas that are expected to be writable (/var, /tmp. even /etc for /etc/resolv.conf)
One simple idea is to just 'tar' up the filesystem, and untar it on another OpenVz distro. (I'm sure someone has made a bootable OpenVz distro..)
If you want a real bootable ISO, there are a LOT of different options. For example, you could have the kernel mount the ISO as root. Or you could boot to a RAMDisk as root, and unpack the filesystem you need. Or you could mount the ISO as root with an AUFS overlay filesystem. Or you could mount some directories as a SquashFS filesystem onto a RAM root.
But if you really want simplicity in "moving VMs around", look into Docker. It has a simple way to push a filesystem up to a public or private server, then download it on the other side, but save bandwidth on common elements like the OS and Apache installs. (If you do it right.)
Our Symfony2 webapp uses the Assetic watcher in development mode to re-compile assets on the go.
The webapp runs in a Docker container which runs in a Vagrant VM (Ubuntu 12.04 Precise).
The host is OSX 10.9 Mavericks and it shares the code folder with the VM through a NFS (v3) share and the code is mounted in the container via a host/guest volume in Docker.
Since inotify seems to not be able to detect file modifications over NFSv3, the watcher works in polling mode which can be very slow (~1/2 minutes to detect the modification).
I've read that NFSv4 is inotify compliant but I did not found any good ressource on that.
Is there a way to make NFS/inotify works together?
Unfortunately, inotify cannot work on NFS. inotify works by hooking itself in the VFS (virtual filesystem) layer, in the kernel. Whenever a modification happens, inotify knows about it, because the modification happens on the same machine, therefore in the same kernel — which makes the whole thing possible.
With NFS, modifications happen on the server, and notifications are expected on the client. But the NFS doesn't notify the clients when a change is made. Otherwise, it wouldn't scale. NFS has been designed (and operated) to have thousands of clients on a single server. Imagine if you do a tiny change, and the server has to push it to all clients!
Of course, you could say "hey, there should be a subscription mechanism in the NFS protocol, so that clients can tell the server that they want to know about changes happening in a specific location". Well, NFS was designed 30 years ago, so forgive them for not including this subscription/notification system :-)
I'm not familiar with Assetic, but maybe you could have a custom script to watch for changes manually, and re-compile assets each time you detect a change. Just walk through the directory containing the source for the assets, keep track of the mtime of each file in an associative array, and each time you detect a new file (or a new mtime), recompile. Boom!
See also this other SO question about inotify and NFS.
Here is a plugin which aim to solve this: https://github.com/mhallin/vagrant-notify-forwarder
Just install it and reload your boxes to have inotify notifications forwarded to your guests machine:
vagrant plugin install vagrant-notify-forwarder
You might be interested in this tool called Guard it listens to the file changes made on host OS, and then on Guest it pulls and update those. This worked for me, and now my assets are updated almost instantaneously.
https://serverfault.com/questions/453826/vagrant-shared-folder-and-file-change-events
Can anyone tell how I might best mirror selected files and folders to a NAS, (Network Addrssable Storage) box from a Linux workstation in real-time?
These are very large files, (> 50GB) and are being continually modified, so I would only like to change those portions of the files that have been changed, added or deleted.
FYI: These files are actually Virtual Box virtual hard disk (VDI) files.
I discovered that my Synology DS211J NAS can run an RSync service. So I enabled that and used lsyncd for the live mirror... the VirtualBox VMs... all works very well.
Rsync only synchronises the parts of files that have change and so is very efficient at synchronising large files.
Of the solutions that #awm mentioned, only drbd provides block-level, realtime synchronization. The other tools will meet your goal of only propagating deltas, but they operate asynchronously. In fact, rsync will work just as well in this case, since you're not trying to provide bi-directional synchronization.
For drbd to provide block-level replication, you need need to install the drbd kernel modules and userspace tools on both the workstation on the NAS...which means this solution is only appropriate if your NAS is actually a fairly generic Linux box over which you have a great deal of control.
Before hand I just want to suggest that you don't do this. You can easily bottlenet your network and NAS and cause all sorts of problem on your host.
That being said, these claim they can do it:
Unison can be found at: http://www.cis.upenn.edu/~bcpierce/unison/
PeerSoft can do it too: http://www.peersoftware.com/products/peersync/peersyncserver/overview.aspx
Maybe - http://www.drbd.org/