OpenVZ Virtuozzo Containers Wiki - User contributions [en]

Introduction to virtualization

2008-11-30T17:39:00Z

Robe: added hp labs link

Virtualization is a framework or methodology of dividing the resources of a computer into multiple execution environments. Virtualization techniques create multiple isolated partitions — Virtual Machines (VM) or [[Virtual Environment]]s ([[VE]]s) — on a single physical server.

== Techniques ==
There are several kinds of virtualization techniques which provide similar features but differ in the degree of abstraction and the methods used for virtualization.

=== Virtual machines (VMs) ===
'''Virtual machines''' emulate some real or fictional hardware, which in turn requires real resources from the ''host'' (the machine running the VMs). This approach, used by most ''system emulators'', allows the emulator to run an arbitrary ''guest operating system'' without modifications because guest OS is not aware that it is not running on real hardware. The main issue with this approach is that some CPU instructions require additional privileges and may not be executed in user space thus requiring a ''virtual machines monitor'' (VMM) to analyze executed code and make it safe on-the-fly. Hardware emulation approach is used by [http://www.vmware.com/ VMware] products, [http://fabrice.bellard.free.fr/qemu/ QEMU], [http://parallels.com/ Parallels] and [http://www.microsoft.com/windowsserversystem/virtualserver/default.mspx Microsoft Virtual Server].

=== Paravirtualization ===
This technique also requires a VMM, but most of its work is performed in the ''guest OS'' code, which in turn is ''modified'' to support this VMM and avoid unnecessary use of privileged instructions. The paravirtualization technique also enables running different OSs on a single server, but requires them to be ported, i.e. they should "know" they are running under the hypervisor. The paravirtualization approach is used by products such as [http://www.xensource.com/xen/ Xen] and [http://user-mode-linux.sourceforge.net/ UML].

=== Virtualization on the OS level ===
Most applications running on a server can easily share a machine with others, if they could be isolated and secured. Further, in most situations, different operating systems are not required on the same server, merely multiple instances of a single ''operating system''. OS-level virtualization systems have been designed to provide the required isolation and security to run multiple applications or copies of the same OS (but different distributions of the OS) on the same server. [http://openvz.org/ OpenVZ], [http://www.swsoft.com/products/virtuozzo Virtuozzo], [http://linux-vserver.org/ Linux-VServer], [http://www.sun.com/bigadmin/content/zones/ Solaris Zones] and [http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/jail.html FreeBSD Jails] are examples of OS-level virtualization.

== Short comparison ==
The three techniques differ in complexity of implementation, breadth of OS support, performance in comparison with standalone server, and level of access to common resources. For example, VMs have wider scope of usage, but poor performance. Para-VMs have better performance, but can support fewer OSs because of need to modify the original OSs.

Virtualization on the OS level provides the best performance and scalability compared to other approaches. Performance difference of such systems can be as low as 1…3%, comparing with that of a standalone server. [[Virtual Environment]]s are usually also much simpler to administer as all of them can be accessed and administered from the host system. Generally, such systems are the best choice for server consolidation of same OS workloads.

== Where to go further ==
If you've decided to try OpenVZ virtualization solution go to [[Quick installation|OpenVZ installation]] section.

== External links ==
* [http://en.wikipedia.org/wiki/Operating_system-level_virtualization wikipedia: Operating system-level virtualization]
* [http://www.hpl.hp.com/techreports/2007/HPL-2007-59R1.pdf HP Labs: Performance Evaluation of Virtualization Technologies for Server Consolidation]

[[Category: Technology]]
[[Category: Concepts]]

Deploying Debian VEs without Templates

2008-11-29T22:19:13Z

Robe: /* A working solution */

Installing Debian Virtual Environments without relying on a precreated template has many advantages and a few drawbacks. This article tries to outline those factors and provide a possible solution to reduce the amount of work needed for template-less Debian deployments.

== Templates ==

[[Template|Templates]] are at the heart of the OpenVZ VE creation process. A "template cache" is basically a tarball consisting of a minimum operating system installation of a given Linux flavor.

== Reasons for pre-built templates ==

=== Very fast VE deployment ===

Deploying a new VE with a tarball reduces the work needed to extracting said tar archive, so the deployment speed can't be any faster. It's possible that certain vzfs optimizations rely on templates being deployed from a specific cached template.

=== Template can contain complex modifications ===

Since templates can contain any files with any given content, you can deploy heavily modified VEs without any problems.

=== Access to a package repository ===

Running a bootstrapper instead of using templates requires access to a package repository, which might not be feasible in certain environments.

== Reasons against pre-built templates ==

=== Management of tarballs can be tedious ===

Managing templates in a non-trivial environment can become it's own demanding task, if taken seriously. The templates have to be updated constantly to reflect new security updates or operating system point releases. And with every updated template, said templates have to be distributed to all Hardware Nodes where they are used.

Experience has shown, that quality is one of the first things being cut in operations/production environments when being time constrained, so preventing one source of constant work improves quality and security instantly and irrevocably.

=== Templates are of questionable security ===

Pre-built templates, especially those which can be downloaded from the internet, are of doubtful trustworthiness. It's trivial to open backdoors, install keyloggers or run DDoS clients if you have full control of the binaries which are going to be run in a VE.

=== It's not needed after all ===

With Debian, there is no reason to actually use pre-built templates if you're not time-constrained in the deployment process and have other means of managing your configuration.

Since <tt>debootstrap</tt> is the tool at the core of every Debian installation it doesn't matter if it's run by the [http://wiki.debian.org/DebianInstaller Debian Installer], during template creation, by hand or even in a completely different Linux distribution.

Management of configuration files by means of templates is a non-sustainable way of doing Configuration Management. In environments with few (if any) changes this can work out nicely, but in more agile/complex environments a proper Configuration Management solution should be used.

== Basic Steps ==

The basic steps needed to deploy Debian VEs are outlined in [[Debian template creation]].

== A working solution ==

To automate the process of deploying VEs with <tt>debootstrap</tt> a bit of shell-scripting glue is needed.

A work-in-progress version of such a tool can be found at https://workbench.amd.co.at/hg/vzstuff/. To get a local copy you need a [http://www.selenic.com/mercurial/wiki/ mercurial] client installed and then run the following command:

hg clone https://workbench.amd.co.at/hg/vzstuff/

Following the instructions in the README file should get you started nicely.

[[Category: Templates]]
[[Category: Debian]]

Deploying Debian VEs without Templates

2008-11-29T21:07:14Z

Robe: /* It's not needed after all */

Installing Debian Virtual Environments without relying on a precreated template has many advantages and a few drawbacks. This article tries to outline those factors and provide a possible solution to reduce the amount of work needed for template-less Debian deployments.

== Templates ==

[[Template|Templates]] are at the heart of the OpenVZ VE creation process. A "template cache" is basically a tarball consisting of a minimum operating system installation of a given Linux flavor.

== Reasons for pre-built templates ==

=== Very fast VE deployment ===

Deploying a new VE with a tarball reduces the work needed to extracting said tar archive, so the deployment speed can't be any faster. It's possible that certain vzfs optimizations rely on templates being deployed from a specific cached template.

=== Template can contain complex modifications ===

Since templates can contain any files with any given content, you can deploy heavily modified VEs without any problems.

=== Access to a package repository ===

Running a bootstrapper instead of using templates requires access to a package repository, which might not be feasible in certain environments.

== Reasons against pre-built templates ==

=== Management of tarballs can be tedious ===

Managing templates in a non-trivial environment can become it's own demanding task, if taken seriously. The templates have to be updated constantly to reflect new security updates or operating system point releases. And with every updated template, said templates have to be distributed to all Hardware Nodes where they are used.

Experience has shown, that quality is one of the first things being cut in operations/production environments when being time constrained, so preventing one source of constant work improves quality and security instantly and irrevocably.

=== Templates are of questionable security ===

Pre-built templates, especially those which can be downloaded from the internet, are of doubtful trustworthiness. It's trivial to open backdoors, install keyloggers or run DDoS clients if you have full control of the binaries which are going to be run in a VE.

=== It's not needed after all ===

With Debian, there is no reason to actually use pre-built templates if you're not time-constrained in the deployment process and have other means of managing your configuration.

Since <tt>debootstrap</tt> is the tool at the core of every Debian installation it doesn't matter if it's run by the [http://wiki.debian.org/DebianInstaller Debian Installer], during template creation, by hand or even in a completely different Linux distribution.

Management of configuration files by means of templates is a non-sustainable way of doing Configuration Management. In environments with few (if any) changes this can work out nicely, but in more agile/complex environments a proper Configuration Management solution should be used.

== Basic Steps ==

The basic steps needed to deploy Debian VEs are outlined in [[Debian template creation]].

== A working solution ==

To automate the process of deploying VEs with <tt>debootstrap</tt> a bit of shell-scripting glue is needed.

A work-in-progress version of such a tool can be found at https://workbench.amd.co.at/hg/vzstuff/. To get a local copy you need a [http://www.selenic.com/mercurial/wiki/ mercurial] client installed and then run the following command:

hg clone -r stable https://workbench.amd.co.at/hg/vzstuff/

Following the instructions in the README file should get you started nicely.

[[Category: Templates]]
[[Category: Debian]]

Deploying Debian VEs without Templates

2008-11-29T20:57:32Z

Robe: /* Tarballs are of questionable security */

Installing Debian Virtual Environments without relying on a precreated template has many advantages and a few drawbacks. This article tries to outline those factors and provide a possible solution to reduce the amount of work needed for template-less Debian deployments.

== Templates ==

[[Template|Templates]] are at the heart of the OpenVZ VE creation process. A "template cache" is basically a tarball consisting of a minimum operating system installation of a given Linux flavor.

== Reasons for pre-built templates ==

=== Very fast VE deployment ===

Deploying a new VE with a tarball reduces the work needed to extracting said tar archive, so the deployment speed can't be any faster. It's possible that certain vzfs optimizations rely on templates being deployed from a specific cached template.

=== Template can contain complex modifications ===

Since templates can contain any files with any given content, you can deploy heavily modified VEs without any problems.

=== Access to a package repository ===

Running a bootstrapper instead of using templates requires access to a package repository, which might not be feasible in certain environments.

== Reasons against pre-built templates ==

=== Management of tarballs can be tedious ===

Managing templates in a non-trivial environment can become it's own demanding task, if taken seriously. The templates have to be updated constantly to reflect new security updates or operating system point releases. And with every updated template, said templates have to be distributed to all Hardware Nodes where they are used.

Experience has shown, that quality is one of the first things being cut in operations/production environments when being time constrained, so preventing one source of constant work improves quality and security instantly and irrevocably.

=== Templates are of questionable security ===

Pre-built templates, especially those which can be downloaded from the internet, are of doubtful trustworthiness. It's trivial to open backdoors, install keyloggers or run DDoS clients if you have full control of the binaries which are going to be run in a VE.

=== It's not needed after all ===

With Debian, there is no reason to actually use pre-built templates if you're not time-constrained in the deployment process and have other means of managing your configuration, since <tt>debootstrap</tt> is the tool at the core of every Debian installation and it doesn't matter if it's run by the [http://wiki.debian.org/DebianInstaller|Debian Installer], by hand or a completely different distribution.

== Basic Steps ==

The basic steps needed to deploy Debian VEs are outlined in [[Debian template creation]].

== A working solution ==

To automate the process of deploying VEs with <tt>debootstrap</tt> a bit of shell-scripting glue is needed.

A work-in-progress version of such a tool can be found at https://workbench.amd.co.at/hg/vzstuff/. To get a local copy you need a [http://www.selenic.com/mercurial/wiki/ mercurial] client installed and then run the following command:

hg clone -r stable https://workbench.amd.co.at/hg/vzstuff/

Following the instructions in the README file should get you started nicely.

[[Category: Templates]]
[[Category: Debian]]

Deploying Debian VEs without Templates

2008-11-29T20:57:03Z

Robe: /* Management of tarballs can be tedious */

Installing Debian Virtual Environments without relying on a precreated template has many advantages and a few drawbacks. This article tries to outline those factors and provide a possible solution to reduce the amount of work needed for template-less Debian deployments.

== Templates ==

[[Template|Templates]] are at the heart of the OpenVZ VE creation process. A "template cache" is basically a tarball consisting of a minimum operating system installation of a given Linux flavor.

== Reasons for pre-built templates ==

=== Very fast VE deployment ===

Deploying a new VE with a tarball reduces the work needed to extracting said tar archive, so the deployment speed can't be any faster. It's possible that certain vzfs optimizations rely on templates being deployed from a specific cached template.

=== Template can contain complex modifications ===

Since templates can contain any files with any given content, you can deploy heavily modified VEs without any problems.

=== Access to a package repository ===

Running a bootstrapper instead of using templates requires access to a package repository, which might not be feasible in certain environments.

== Reasons against pre-built templates ==

=== Management of tarballs can be tedious ===

Managing templates in a non-trivial environment can become it's own demanding task, if taken seriously. The templates have to be updated constantly to reflect new security updates or operating system point releases. And with every updated template, said templates have to be distributed to all Hardware Nodes where they are used.

Experience has shown, that quality is one of the first things being cut in operations/production environments when being time constrained, so preventing one source of constant work improves quality and security instantly and irrevocably.

=== Tarballs are of questionable security ===

Pre-built templates, especially those which can be downloaded from the internet, are of doubtful trustworthiness. It's trivial to open backdoors, install keyloggers or run DDoS clients if you have full control of the binaries which are going to be run in a VE.

=== It's not needed after all ===

With Debian, there is no reason to actually use pre-built templates if you're not time-constrained in the deployment process and have other means of managing your configuration, since <tt>debootstrap</tt> is the tool at the core of every Debian installation and it doesn't matter if it's run by the [http://wiki.debian.org/DebianInstaller|Debian Installer], by hand or a completely different distribution.

== Basic Steps ==

The basic steps needed to deploy Debian VEs are outlined in [[Debian template creation]].

== A working solution ==

To automate the process of deploying VEs with <tt>debootstrap</tt> a bit of shell-scripting glue is needed.

A work-in-progress version of such a tool can be found at https://workbench.amd.co.at/hg/vzstuff/. To get a local copy you need a [http://www.selenic.com/mercurial/wiki/ mercurial] client installed and then run the following command:

hg clone -r stable https://workbench.amd.co.at/hg/vzstuff/

Following the instructions in the README file should get you started nicely.

[[Category: Templates]]
[[Category: Debian]]

Deploying Debian VEs without Templates

2008-11-29T20:52:00Z

Robe:

Installing Debian Virtual Environments without relying on a precreated template has many advantages and a few drawbacks. This article tries to outline those factors and provide a possible solution to reduce the amount of work needed for template-less Debian deployments.

== Templates ==

[[Template|Templates]] are at the heart of the OpenVZ VE creation process. A "template cache" is basically a tarball consisting of a minimum operating system installation of a given Linux flavor.

== Reasons for pre-built templates ==

=== Very fast VE deployment ===

Deploying a new VE with a tarball reduces the work needed to extracting said tar archive, so the deployment speed can't be any faster. It's possible that certain vzfs optimizations rely on templates being deployed from a specific cached template.

=== Template can contain complex modifications ===

Since templates can contain any files with any given content, you can deploy heavily modified VEs without any problems.

=== Access to a package repository ===

Running a bootstrapper instead of using templates requires access to a package repository, which might not be feasible in certain environments.

== Reasons against pre-built templates ==

=== Management of tarballs can be tedious ===

Managing templates in a non-trivial environment can become it's own demanding task, if taken seriously. The templates have to be updated constantly to reflect new security updates or point releases. And with every updated template, said templates have to be distributed to all Hardware Nodes where they are used.

Experience has shown, that quality is one of the first things being cut in operations/production environments when being time constrained, so preventing one source of constant work improves quality and security instantly.

=== Tarballs are of questionable security ===

Pre-built templates, especially those which can be downloaded from the internet, are of doubtful trustworthiness. It's trivial to open backdoors, install keyloggers or run DDoS clients if you have full control of the binaries which are going to be run in a VE.

=== It's not needed after all ===

With Debian, there is no reason to actually use pre-built templates if you're not time-constrained in the deployment process and have other means of managing your configuration, since <tt>debootstrap</tt> is the tool at the core of every Debian installation and it doesn't matter if it's run by the [http://wiki.debian.org/DebianInstaller|Debian Installer], by hand or a completely different distribution.

== Basic Steps ==

The basic steps needed to deploy Debian VEs are outlined in [[Debian template creation]].

== A working solution ==

To automate the process of deploying VEs with <tt>debootstrap</tt> a bit of shell-scripting glue is needed.

A work-in-progress version of such a tool can be found at https://workbench.amd.co.at/hg/vzstuff/. To get a local copy you need a [http://www.selenic.com/mercurial/wiki/ mercurial] client installed and then run the following command:

hg clone -r stable https://workbench.amd.co.at/hg/vzstuff/

Following the instructions in the README file should get you started nicely.

[[Category: Templates]]
[[Category: Debian]]

Deploying Debian VEs without Templates

2008-11-29T20:48:42Z

Robe: New page: Installing Debian Virtual Environments without relying on a precreated template has many advantages and a few drawbacks. == Templates == Templates are at the heart of the O...

Installing Debian Virtual Environments without relying on a precreated template has many advantages and a few drawbacks.

== Templates ==

[[Template|Templates]] are at the heart of the OpenVZ VE creation process. A "template cache" is basically a tarball consisting of a minimum operating system installation of a given Linux flavor.

== Reasons for pre-built templates ==

=== Very fast VE deployment ===

Deploying a new VE with a tarball reduces the work needed to extracting said tar archive, so the deployment speed can't be any faster. It's possible that certain vzfs optimizations rely on templates being deployed from a specific cached template.

=== Template can contain complex modifications ===

Since templates can contain any files with any given content, you can deploy heavily modified VEs without any problems.

=== Access to a package repository ===

Running a bootstrapper instead of using templates requires access to a package repository, which might not be feasible in certain environments.

== Reasons against pre-built templates ==

=== Management of tarballs can be tedious ===

Managing templates in a non-trivial environment can become it's own demanding task, if taken seriously. The templates have to be updated constantly to reflect new security updates or point releases. And with every updated template, said templates have to be distributed to all Hardware Nodes where they are used.

Experience has shown, that quality is one of the first things being cut in operations/production environments when being time constrained, so preventing one source of constant work improves quality and security instantly.

=== Tarballs are of questionable security ===

Pre-built templates, especially those which can be downloaded from the internet, are of doubtful trustworthiness. It's trivial to open backdoors, install keyloggers or run DDoS clients if you have full control of the binaries which are going to be run in a VE.

=== It's not needed after all ===

With Debian, there is no reason to actually use pre-built templates if you're not time-constrained in the deployment process and have other means of managing your configuration, since <tt>debootstrap</tt> is the tool at the core of every Debian installation and it doesn't matter if it's run by the [http://wiki.debian.org/DebianInstaller|Debian Installer], by hand or a completely different distribution.

== Basic Steps ==

The basic steps needed to deploy Debian VEs are outlined in [[Debian template creation]].

== A working solution ==

To automate the process of deploying VEs with <tt>debootstrap</tt> a bit of shell-scripting glue is needed.

A work-in-progress version of such a tool can be found at https://workbench.amd.co.at/hg/vzstuff/. To get a local copy you need a [http://www.selenic.com/mercurial/wiki/ mercurial] client installed and then run the following command:

hg clone -r stable https://workbench.amd.co.at/hg/vzstuff/

Following the instructions in the README file should get you started nicely.

[[Category: Templates]]
[[Category: Debian]]