Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why You Should Be Using Virtualisation In Your Development Environment

morethanseven.net

Post reply on HN
Print view View original

11–20 of 44 posts

Re: Why You Should Be Using Virtualisation In Your Development Environment

#11

Post by reynolds »

JofArnold wrote: post #10
JofArnold wrote: post #7

Not strictly in the spirit of the post, but I use a nice VM setup I thoroughly recommend: - Host: OSX (2.4GHz i5, 8GB ram) - Guest1: Ubuntu 10.10 (1.5GB ram allocated; acts as a LAMP server, available to Host and other Guests) - Guest2: WinXP (1.5GB ram allocated - I use it for IE and for Xara) This config eats RAM, but affords so many advantages: 1/ Makes my LAMP server portable. Can set up on new computer in no tim…

PS, if anyone knows a solution to the file access speed issue (not just the filesystem of the guest, but also what ever you share with it from the host) please tell me. Parallels, VMWare Fusion and VirtualBox all have this issue and it drives me mad sometimes!

I'm not sure if this helps in your situation, but when I'm running VMware I don't share any local directories. I use rsync to manage the virtual server directories since it's similar to how I deploy to my remote servers.

Having to manually "deploy" code to a local virtual server can be tedious, so running a background process that watches your local directories for changes helps a lot.

Re: Why You Should Be Using Virtualisation In Your Development Environment

#12

Post by mathias_10gen »

someone_here wrote: post #6
FiReaNG3L wrote: post #5

Note that its pretty much a must if you plan to have a MongoDB server as part of your dev environment on your home box - Mongo by design eats all the RAM it can find to map files to, and if you have Apache, Solr and MySQL running on the same box, things can get ugly :)

Why do applications think they can manage my memory better than my kernel?

Actually, MongoDB does leave memory management to the kernel by using MMAP to access data files. Most kernels will allocate a lot of memory to the disk cache, which can make it look like mongo is eating all of your ram.

Re: Why You Should Be Using Virtualisation In Your Development Environment

#15

Post by aaronblohowiak »

JofArnold wrote: post #10
JofArnold wrote: post #7

Not strictly in the spirit of the post, but I use a nice VM setup I thoroughly recommend: - Host: OSX (2.4GHz i5, 8GB ram) - Guest1: Ubuntu 10.10 (1.5GB ram allocated; acts as a LAMP server, available to Host and other Guests) - Guest2: WinXP (1.5GB ram allocated - I use it for IE and for Xara) This config eats RAM, but affords so many advantages: 1/ Makes my LAMP server portable. Can set up on new computer in no tim…

PS, if anyone knows a solution to the file access speed issue (not just the filesystem of the guest, but also what ever you share with it from the host) please tell me. Parallels, VMWare Fusion and VirtualBox all have this issue and it drives me mad sometimes!

SSD will help make it faster, but the OS will also be that much faster so it won't seem faster by comparison, only in an absolute sense.

Re: Why You Should Be Using Virtualisation In Your Development Environment

#16

Post by ciniglio »

reynolds wrote: post #11
JofArnold wrote: post #10

Earlier quoted context omitted.

PS, if anyone knows a solution to the file access speed issue (not just the filesystem of the guest, but also what ever you share with it from the host) please tell me. Parallels, VMWare Fusion and VirtualBox all have this issue and it drives me mad sometimes!

I'm not sure if this helps in your situation, but when I'm running VMware I don't share any local directories. I use rsync to manage the virtual server directories since it's similar to how I deploy to my remote servers. Having to manually "deploy" code to a local virtual server can be tedious, so running a background process that watches your local directories for changes helps a lot.

Can you elaborate on that background process? Is that something built into rsync?

Re: Why You Should Be Using Virtualisation In Your Development Environment

#17

Post by SkyMarshal »

I've also found it's generally better to keep your base installation as sparse as possible, and use virtual machines for anything that does not absolutely need to be on the host.

That way you can set up servers, experiment with new platforms and/or applications, hack^Wlearn config files and system internals, etc. without risk of bogging down or blowing up your machine and having no recourse but a full reinstall and reconfig.

I've got core Ubuntu Server, OpenSuse, and CentOS server images, that include extras like git-core, htop, ssh, and a few other utilities I universally depend on, and that I can copy, deploy, and configure for whatever specialized purpose that comes up.

<3 it.

Re: Why You Should Be Using Virtualisation In Your Development Environment

#18

Post by reynolds »

ciniglio wrote: post #16
reynolds wrote: post #11

Earlier quoted context omitted.

I'm not sure if this helps in your situation, but when I'm running VMware I don't share any local directories. I use rsync to manage the virtual server directories since it's similar to how I deploy to my remote servers. Having to manually "deploy" code to a local virtual server can be tedious, so running a background process that watches your local directories for changes helps a lot.

Can you elaborate on that background process? Is that something built into rsync?

It's actually something I've been working on that I want to put up on github. I hacked up a Python version of it as a proof-of-concept but rewrote it in C as an installable executable using autotools.

Basically I tell it which directory I want it to watch for changes and it does automatic syncing by piping rsync. I keep a local and remote signature of the files and their timestamps. When it first starts up, it pulls the server sig file and compares it to the local one. If there's a mismatch, the server is updated. From there it manages the signatures locally until they're different.

Writing the sig file to the remote server is done in the same rsync pass because it's stored in the local directory as a dotfile.

I realize rsync does its own checksums, but using my own crude signature files makes it so I don't have to keep calling rsync. I only call it when something changes.

I also have some stuff I'm working on that ties into auto-restarting servers when syncing finishes, rolling server deployments for no downtime, db migrations, etc.

Re: Why You Should Be Using Virtualisation In Your Development Environment

#19

Post by colbyolson »

JofArnold wrote: post #10
JofArnold wrote: post #7

Not strictly in the spirit of the post, but I use a nice VM setup I thoroughly recommend: - Host: OSX (2.4GHz i5, 8GB ram) - Guest1: Ubuntu 10.10 (1.5GB ram allocated; acts as a LAMP server, available to Host and other Guests) - Guest2: WinXP (1.5GB ram allocated - I use it for IE and for Xara) This config eats RAM, but affords so many advantages: 1/ Makes my LAMP server portable. Can set up on new computer in no tim…

PS, if anyone knows a solution to the file access speed issue (not just the filesystem of the guest, but also what ever you share with it from the host) please tell me. Parallels, VMWare Fusion and VirtualBox all have this issue and it drives me mad sometimes!

From the experience I've had with running Parallels and the like, I disable any sharing of drives. I dont need drag and drop files from and to each one. After disabling that, I see better performance.

Disabling options like Application sharing, Drive sharing, video card 3D support, and the like will help. If you dont need it, turn it off.

Re: Why You Should Be Using Virtualisation In Your Development Environment

#20

Post by reynolds »

needyballsack wrote: post #14

How do you handle version control in this environment? Locally on the mac or in the virtual server?

The way I do it is to write all of the code locally and use git/svn/hg/whatever locally. I then rsync my changes to the virtual machine when I'm ready to test.
Post reply on HN