Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jozef (8299)

jozef
  (email not shown publicly)
http://jozef.kutej.net/
Jabber: jozef@kutej.net

Journal of jozef (8299)

Friday December 04, 2009
02:49 PM

when virtualization is too expensive

[ #39979 ]

Yes the thing that turns your single computer to multiple computers. Why should it be expensive? Simply because the virtual machines are not sharing one disk space and one memory. To make the the virtual system run smoothly, it needs some decent amount of dedicated memory and a disk volume with some reserve so it doesn't have to be resized too often.

First find the reasons for doing virtualization, why would anyone want to run multiple machines on a single hw? Most likely to clearly separate the programs and the whole operating systems. Give the strictly defined virtual hw resources, limit the access for security reasons. And also to add one level of abstraction which then allows systems to live in a cloud. But that is a different topic.

Let's search for the solutions how not to do virtualization and fulfil some (!) of the requirements of it. Mainly the clear files and whole system separation for Perl development.

If just Perl is in the play, then compiling and installing user own Perl is an option. Simply having the Perl binary and all the installed CPAN modules in the $HOME directory of the user.

If Apache is needed or some extra binary libraries, it is still possible to compile and install to the user home, but it is quite a lot of "hand work" and not every one has time and passion to do it. Much more simple way is to use chroot. What chroot does is that it sets root of the filesystem for the child processes to a folder. And as we are in UNIX, where (nearly) anything is a file, this means a different machine. Both systems, the parent and the chroot-ed, still share the same /proc, /dev, network devices etc., but the separation is enough to be able to install programs with standard distribution commands and run them. Fair enough to have chroot-ed machine as a development machine. Benefiting of shared memory and disks pace, easy file sharing (one filesystem) and not having to maintain virtualization sw.

Here is how to create a chrooted system on Debian and switch to it:

debootstrap lenny /usr/chroot/$MACHINENAME
echo ${MACHINENAME}_chroot > /usr/chroot/$MACHINENAME/etc/debian_chroot
chroot /usr/chroot/$MACHINENAME su -

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I've been a heavy user of Linux vservers (see also: OpenVZ and the other one whose name I forget; and BSD 'jails') for a number of years. They are similar in concept to your chroot solution except much more convenient to use. They are lightweight because the virtual servers don't run their own kernels - they share the host kernel but with key structures like the process table partitioned into separate namespaces.

    I've found this type of virtualisation to be invaluable in the 'staging' or 'User Acceptance

  • One thing we see coming up in our giant work VM system is deduplication, where the VM software natively lets you copy an entire VM machine with nearly zero disk cost, and can reuse the same disk for multiple live VMs.

    I am really hoping this filters down to commonly available VM software soon.