I often use Vagrant VMs, and you can configure them to link, say /var/www to c:\your\projects or whatever. (The Laravel community generally uses "Homestead" Vagrant VMs, which gets you set up with the necessary PHP version and such along with all the Laravel stuff.)
Therefore, my editor is running on Windows and editing files in c:\your\projects\whatever..., and then I can immediately test saved changes in the VM.
OK Vagrant is looking pretty good. Apparently there is a Vagrant image for php7 dev that already exists:
https://github.com/rlerdorf/php7dev
I haven't used Vagrant but I hear it's extremely popular. I generally have a number of different VMs created through VirtualBox. Sometimes you don't even have to create more than one since it allows you to take snapshots. For instance you could run a snapshot with PHP7 RC4 and another snapshot with RC3, but they'd both be on the same VM. Then you could branch off those as well, and I believe you can spinoff an entire VM from a snapshot, too. Most of these features used to be exclusive to VMware, but VirtualBox has caught up to them in the last couple years (and it's open-source and free).
I use Oracle's VirtualBox, which is free, more/less. I typically run FreeBSD on it, in accordance with my known flaming zeal, but I also currently have one successfully running CentOS.
Now, granted, I run it on Windows, which is what the company wants me to use. But I've run VBox on other systems in the past (if it'll run on FreeBSD, it will run on Linux, almost always --- typically as Linux is a bigger target the FreeBSD version is a port from it ... ).
If you want to run multiple VM's at one time, you'll need some hoss hardware: however multi-core CPUs and multiple GB of RAM are pretty common these days. I'm not quite sure that VBox plays nice with multi-core CPUs under my 64-bit Win7 installation, so I all my VMs here are single-core (think about 5-10 year old hardware; that's what I typically set up for resources for my VMs). I have about 6G RAM, so I typically run 1 or 2 GB RAM on my VMs. I manage it all with the Oracle VM VirtualBox Manager, although in some circumstances we run the CLI programs to start VMs at Windows startup. This would be possible in the Nixen fairly easily via cron's @ (or your Linuxen may have other ways you'd prefer).
dalecosp;11051481 wrote:I'm not quite sure that VBox plays nice with multi-core CPUs under my 64-bit Win7 installation, so I all my VMs here are single-core (think about 5-10 year old hardware; that's what I typically set up for resources for my VMs).
They do. You can specify how many cores a VM will use under Settings > System and then under the Processor tab. I have run two VMs simulataneously with my quad core system (2 for me, 1 each for the VMs) as well as 2 and 2 with a single VM. I am also running Windows 7 x64.
So I spent nearly two full days upgrading my workstation to Ubuntu 14.04.3 LTS and I see that Ubuntu has package installers for various virtualbox bits:
$ apt-cache search virtualbox | grep "^virtualbox"
virtualbox - x86 virtualization solution - base binaries
virtualbox-dbg - x86 virtualization solution - debugging symbols
virtualbox-dkms - x86 virtualization solution - kernel module sources for dkms
virtualbox-guest-additions-iso - guest additions iso image for VirtualBox
virtualbox-guest-dkms - x86 virtualization solution - guest addition module source for dkms
virtualbox-guest-source - x86 virtualization solution - guest addition module source
virtualbox-guest-utils - x86 virtualization solution - non-X11 guest utilities
virtualbox-guest-x11 - x86 virtualization solution - X11 guest utilities
virtualbox-qt - x86 virtualization solution - Qt based user interface
virtualbox-source - x86 virtualization solution - kernel module sourceOne can also install vagrant:
$ apt-cache search vagrant
vagrant - Tool for building and distributing virtualized development environmentsI also found this post Why should I use Vagrant instead of just VirtualBox?. Looks like Vagrant runs on top of virtual box and has a significant value-add.
On the other hand, I'm a bit suspicious or running virtual machines created by someone else. This seems to be one of the chief benefits of Vagrant. Where do these OS images come from? It seems a little suspect to me that I could install virtualbox and suddenly be able to fire up Windows virtual machines without paying license fees to M$. I also wonder how much these virtual machines are sandboxed or whatever. Are they chrooted or something? Jailed? Or can they right my whole file system?
VirtualBox doesn't create virtual machines for you or provide you with OS images. That's all up to you. VirtualBox is just, for lack of better explanation, virtualization software. You still have to create the virtual machines and provide the OS image yourself. Since Linux is free it's incredibly popular for this sort of situation. Sounds like Vagrant does a lot of the grunt work for you so perhaps it's the best option. Personally I'd stick with VirtualBox but that's just me.
As for sandboxing the guest OS and the host OS are pretty much separate. It's like having 2 separate PCs sitting next to each other on a table. The level of connectivity depends up to you and your needs. You can control things like shared folders, clipboard, drag & drop, etc. in the settings for each virtual machine.
Bonesnap;11051519 wrote:VirtualBox doesn't create virtual machines for you or provide you with OS images. That's all up to you. VirtualBox is just, for lack of better explanation, virtualization software. You still have to create the virtual machines and provide the OS image yourself. Since Linux is free it's incredibly popular for this sort of situation. Sounds like Vagrant does a lot of the grunt work for you so perhaps it's the best option. Personally I'd stick with VirtualBox but that's just me.
I've watched a rather long video that shows how to install Ubuntu using VirtualBox, but the guy is using VirtualBox for windows. He fails to mention what some of the software is or what a "virtual guest" is but it looks pretty informative. Very time consuming! I can't help but wonder if you can take a snapshot of a VM once you've got it all set up so that you can "branch" it and save to distinct disk images?
Bonesnap;11051519 wrote:As for sandboxing the guest OS and the host OS are pretty much separate. It's like having 2 separate PCs sitting next to each other on a table. The level of connectivity depends up to you and your needs. You can control things like shared folders, clipboard, drag & drop, etc. in the settings for each virtual machine.
I'm not so sure how separate they are. They are definitely using the same physical hard disk. Also, as I mentioned in my original post, I want to run Eclipse on my workstation and have the changed files updated on the virtual machines. I haven't seen vagrant in action yet but if I'm going to install some Ubuntu image created by some company or individual I've never heard of, I expect I would want to be sure that virtual machine CANNOT EVER READ MY WORKSTATION'S FILE SYSTEM.
sneakyimp;11051521 wrote:I've watched a rather long video that shows how to install Ubuntu using VirtualBox, but the guy is using VirtualBox for windows. He fails to mention what some of the software is or what a "virtual guest" is but it looks pretty informative. Very time consuming! I can't help but wonder if you can take a snapshot of a VM once you've got it all set up so that you can "branch" it and save to distinct disk images?
Yes, once you set up your virtual machine, go to the VirtualBox main window, select the VM you have just set up, and click export appliance. This export file can be sent to others to set up the same box. If however you just want to start with the same box as another locally, then in the same VirtualBox main window, right click on your virtual machine and go to clone.
sneakyimp;11051521 wrote:I'm not so sure how separate they are. They are definitely using the same physical hard disk. Also, as I mentioned in my original post, I want to run Eclipse on my workstation and have the changed files updated on the virtual machines. I haven't seen vagrant in action yet but if I'm going to install some Ubuntu image created by some company or individual I've never heard of, I expect I would want to be sure that virtual machine CANNOT EVER READ MY WORKSTATION'S FILE SYSTEM.
The virtual machine is an isolated machine with only access to the virtual disk you create for it. Unless you use Virutalbox's shared folder feature, in which case any folders you choose to share to your machine, will be mounted and accessible within the VM.
I usually just open up a terminal or cmd window, go to the directory where I have the vm, and type "vagrant up". It takes care of launching VirtualBox in command line mode. Just a personal preference thing, not saying it's necessarily better that way. (You can do "vagrant suspend" when you want to close it but save the current state, or "vagrant halt" to do a complete shutdown.)
sneakyimp;11051521 wrote:I've watched a rather long video that shows how to install Ubuntu using VirtualBox, but the guy is using VirtualBox for windows. He fails to mention what some of the software is or what a "virtual guest" is but it looks pretty informative. Very time consuming! I can't help but wonder if you can take a snapshot of a VM once you've got it all set up so that you can "branch" it and save to distinct disk images?
I can sympathize with the lack of explanation regarding terminology; I have run into that issue when learning Linux and all its accompanying fun. Basically the host is your actual computer/OS. You clearly run Linux so your host OS is Linux. A guest OS is simply an OS that runs in a virtual machine, which of course you can have many.
It can be time consuming in the beginning but once you get the hang of it it's not so bad. And yeah, as Derokorian confirmed, you can create separate virtual machines from snapshots. Which is nice because you can create a base for which to branch off of.
Also, I know you don't use Windows, but one neat thing is if you create a virtual disk in the *.vhd format you can actually boot your physical PC from it, even if you don't have an OS on your PC (Windows 7 Ultimate and Enterprise only, though).
sneakyimp;11051521 wrote:I'm not so sure how separate they are. They are definitely using the same physical hard disk. Also, as I mentioned in my original post, I want to run Eclipse on my workstation and have the changed files updated on the virtual machines. I haven't seen vagrant in action yet but if I'm going to install some Ubuntu image created by some company or individual I've never heard of, I expect I would want to be sure that virtual machine CANNOT EVER READ MY WORKSTATION'S FILE SYSTEM.
They are very separate since the guest OS operates solely in a file container (which I believe can be encrypted now in version 5+). It has no knowledge of your host's file system and therefore you can't run a command in your guest and have it accidentally delete something on your host**. Virtual machines are very popular because of this isolation which is why they're frequently used for testing alpha/beta software or software that most would consider "sketchy".
** If you share a folder or directory and you run a command in your guest to do something with that folder then yeah, you'll affect your host installation, but that applies to any kind of mapping between any operating systems. I think this is one area where you can ease your concerns. :p
Bonesnap;11051533 wrote:...or software that most would consider "sketchy".
Yeah, I use a VM to install programs from untrusted sources before they go on my main os. If it bricks my VM, I just revert to the last snapshot. Speaking of snapshot, this is another awesome feature of VirtualBox, when in the main window you can select a vm, and go to the snapshots tab (top right, it defaults to Details) and take a snapshot of the current state. Then you can try something risky and revert to the snapshot oh so easily.
Alrighty thanks a ton for all the info. I think I'm learning toward VirtualBox, but would like to clarify a few things mentioned in this Vagrant vs Virtualbox comparison.
It saith:
Vagrant is used to set up one or more virtual machines by:
Importing pre-made images (called "boxes")
Setting VM-specific settings (IP address, hostnames, port forwarding, memory, etc.)
* Running provisioning software like Puppet or ChefNote that it doesn't install software or set up the machine past loading the VM and setting VirtualBox settings. Think of it as a scripting engine for VirtualBox.
Here are some reasons I've seen for using Vagrant over just VirtualBox.
1. Set Up Multi-VM Networks with Ease
Most of the Vagrant power-user content I've read has been about setting up multiple VMs at the same time. Vagrant gives you a single config file to set these up, enabling you to launch all of them with one command...2. Source Control
By putting the settings in a text file, it enables the configuration to be put under source control. Made some changes last week and accidentally broke the image? Just revert the changes and reload the VM. You can accomplish this with VirtualBox snapshots, but it will take up much more space than just a Vagrantfile.3. Various Platforms
There's a large number of boxes available at sites such as http://vagrantbox.es. This enables you to try various OSes or distributions, applying the same provisioning to set up similar environments.
I don't need multi-VM networks at this point, I'm suspicious of sites like vagrantbox.es (but I can see how this might be quite powerful -- people sharing boxes sounds like good stuff). I dread tackling not just VBox and Vagrant but also Puppet and/or Chef. The one feature of Vagrant that seems immediately helpful and useful for my situation is that maintaining snapshots sounds like it'll involve really big files. I'm guessing these snapshots will be at least the size of the installed OS files and possibly as big as the entire amount of space allocated to the VM -- e.g., ~10GB or more.
Any detail you guys can offer on managing snapshots? For example, I need three VMs, both Ubuntu 14.04.3. One one I want to install PHP 5.5 to test a module. On another, PHP 5.6. On the third, PHP 7. Am I looking at 30GB of files?
sneakyimp;11051551 wrote:Any detail you guys can offer on managing snapshots? For example, I need three VMs, both Ubuntu 14.04.3. One one I want to install PHP 5.5 to test a module. On another, PHP 5.6. On the third, PHP 7. Am I looking at 30GB of files?
From my experience, snapshots are incremental. For example, the Windows 7 virtual machine I have at work, I created a 25GB virtual disk and I have a total of 8 snaphshots. The snapshots take up a total of 38.8GB for an average of 4.85GB per snapshot. For a Linux installation I imagine they'll be smaller. If I look at the actual snapshot files it appears most of the files are between 2-3GB and there's one really large one (22G
, which was the first snapshot I made after I had installed all the Windows updates. The subsequent snapshots are all much smaller. Chances are you're looking at snapshots in the 2-3GB range.
I just took the first snapshot of my CentOS box running PHP7, it took up 1.5GB. Oh and it took less than a minute to create the snapshot.
Can anyone help me get clear on the networking options for this virtual machines? I'm reading the CHM documentation on Virtual Networking and would like to know if I understand this correctly.
6.3 Network Address Translation (NAT)
Virtual machines can connect to the internet but not to each other. Virtual machine and host (i.e., my workstation) are on entirely different networks (i.e., 192.168.1.x for my workstation versus 10.0.x.x for virtual machines) so host cannot "see" virtual machines via network -- no SSH, no HTTP, etc., between host and virtual machines.
6.4 6.4. Network Address Translation Service
Not clear to me how this relates to 6.3, but apparently you can group VMs into named networks so they can interact with each other? Can host contact VMs for ssh, http, etc?
6.5. Bridged networking
Device drive on host is somehow used to route both VM (guest) and host traffic. VMs can communicate with 'outside world.' VMs appear as connected on the network? Host can talk to VMs? How are IP addresses allocated and determined?
6.6. Internal networking
Similar to 6.5, but VMs can only communicate with each other? Traffic is not routed via the host machine's NIC and so it cannot be snooped by Wireshark et. al.
6.7. Host-only networking
Very similar to 6.6 except that a quasi-local-loopback network interface is created which can be snooped by wireshark.
The help file descriptions in the user manual (found here don't make a lot of sense to me.
In regard to VirtualBox disk space and images, the VDI files can be set up as "dynamically allocated", however, unless the guest OS has the ability to dynamically resize its partitions, you still end up with big files. The VDI for my local FreeBSD Virtualbox machine is right at 100GB; the CentOS one, which has less disk space allocated, is over 25GB. I'm not certain, but I would expect the storage scheme for a "server farm" would typically involve some sort of network-file-system or SAN.
As for networking, I simply run them in "Bridged Networking" mode ... they act as servers we can access from anywhere inside the LAN. The "corporate firewall" and the LAN routing is supposed to ensure that they're not accessible to outside.
dalecosp;11058809 wrote:In regard to VirtualBox disk space and images, the VDI files can be set up as "dynamically allocated", however, unless the guest OS has the ability to dynamically resize its partitions, you still end up with big files. The VDI for my local FreeBSD Virtualbox machine is right at 100GB; the CentOS one, which has less disk space allocated, is over 25GB. I'm not certain, but I would expect the storage scheme for a "server farm" would typically involve some sort of network-file-system or SAN.
Thanks for this helpful comment. In my case, I do not need to access these VMs except from the workstation on which they run. I opted for dynamically allocated sizing. I don't think this results in any partition manipulations on my machine's drives. So far, there's just one *.vdi file that's about 2.3GB -- this is just Ubuntu 16 with apache & php on it.
dalecosp;11058809 wrote:As for networking, I simply run them in "Bridged Networking" mode ... they act as servers we can access from anywhere inside the LAN. The "corporate firewall" and the LAN routing is supposed to ensure that they're not accessible to outside.
Thank you for providing a real-world example here. The documentation is pretty prolix but somehow fails to communicate what the different modes mean in any way that I can understand. Reading comprehension has never been my strong suit, but I think the documentation could be a lot clearer--like your post is!
[ATTACH=CONFIG]5425[/ATTACH]
xkcde.pngI recently went through the trouble of setting up an Ubuntu 16 vm using virtualbox and sharing a folder with my workstation (the host) for a Laravel development project. The idea was to set up things so that I can edit the source code and perform git operations on my workstation/host machine while running apache on the vm/guest because laravel 5.4 needs newer features my workstation lacks. Kind of a Pain In The Ass (PITA) for various reasons. I document the steps here both for my own future reference but also to show part of the PITA sandwich.
1) Open VirtualBox and fire up my Ubuntu 16.04 instance.
2) Reset root password, which I had forgotten, on the vm/guest. Helpful video here.
3) Consider cloning the basic VM (which is just a clean Ubuntu 16.04 in my case) because you may not want the following settings applied to your one-single-virtualbox-master-copy instance. I do this by shutting down the VM, right-clicking it in the VirtualBox gui, and selecting Clone.... Give it an informative name, e.g., my-project-vm or something. I chose Linked Clone because I wanted smaller file size and am not concerned about moving this clone away from its linked VirtualBox files.
4) Put the new clone in bridged network mode (settings->network, select 'bridged adapter').
5) Fire the new clone up.
6) Set the clone to use a static ip address. Should probably be different than the vm from which you cloned it (192.168.1.4 in my case). Why do this? If you don't, it may acquire a different IP address every time you fire it up, which can be a real nuisance to keep tracking down. Changing ubuntu-server to static ip address is beyond the scope of these instructions for ubuntu-desktop, just open the Network control panel, select Wired from the connections listed and then click Options.... Then click the IPv4 Settings tab and in the resulting Editing Wired Connection 1 dialog, set Method to Manual. Click Add to add a static IP. with:
Address: 192.168.1.5 (change this if you like)
Netmask: 255.255.255.0 (this might be different on your system, check output of ifconfig from host machine to see what it has for Mask)
Gateway: 192.168.1.1 (this is the IP of my router running DHCP)
In the bottom half of the dialog where is says DNS Servers, enter 192.168.1.1 (ip addr of router running DHCP).
Click Save and close the dialog. Reboot the vm/guest machine. When it reboots, it should try to bind to the new address (192.168.1.5 in this case) on your network.
At this point, you should make sure that your host machine can ssh into the vm -- or at the very least access the vm/guest via browser. Try entering http://192.168.1.5 in browser and make sure you are accessing the vm.
7) Establish a shared folder between my workstation/host computer and the vm/guest computer. I've cloned a repo of a laravel project into a working directory on my workstation (/path/to/my-project) and I want apache on the vm/guest machine t7 serve those laravel source files. For laravel project to even run, apache needs read access to all the files and write access to the storage subdirectory (and all its subdirectories) and also the bootstrap/cache directory (and possibly its subdirectories?). There is useful information in the VirtualBox documentation here. NOTE: setting up a shared folder requires installation of the Guest Additions to the vm/guest machine. This is also discussed earlier on that same page I've linked.
7a) Share a folder on your host machine. You cannot share from the guest/vm machine so you share one on the host and it is accessible to the guest/vm. There are a few ways to get at this setting in VirtualBox. I suggest going to the VM's window and using the menu at the top: Devices->Shared Folders->Shared Folders Settings. This brings up a Settings dialog. Click the Folder-with-plus icon to add a shared folder. This brings up another Add Share dialog. Where it says Folder Path, you can either type in the path on the host machine to be shared or you can select Other... and browse your host machine for the folder you want to share. I choose /path/to/my-project. In the Folder Name input, you'll need to enter a "share name" for it. In my case, I just chose my-project-share. Do NOT check the read-only checkbox. You can check automount if you like, but this means that the guest/vm will have a weird path to the shared folder, something like /media/sf_my-project-share. I only check Make Permanent -- this should make the shared folder available even if we shutdown/reboot the vm, however, we will still have to manually mount the shared folder from our guest/vm to work with it.
7b) Mount the shared folder on the guest/vm. First, create a directory on your guest/vm in the location where you want the shared folder to appear. I chose this:
sneakyimp@guest-vm$ sudo mkdir /var/www/my-projectAccording to section 4.3.1, you can mount the shared folder from the guest/vm with this command (which I've modified to reflect my choices here):
sneakyimp@guest-vm$sudo mount -t vboxsf my-project-share /var/www/my-projectYou should now be able, on your guest/vm, to list the contents of the new folder and see the shared contents from your host machine:
sneakyimp@guest-vm$ ls -al /var/www/my-projectIf you encounter problems or would like to change your mount options, you can use:
sudo umount /var/www/my-projectto unmount the shared folder and try again.
TO BE CONTINUED....(too long for one post)