The Perfect Xen Setup For Debian And Ubuntu

This tutorial provides step-by-step instructions on how to install Xen (version 2) on a Debian Sarge (3.1) system. It should apply to Ubuntu systems with little or no modifications.
Xen lets you create guest operating systems (*nix operating systems like Linux and FreeBSD), so called "virtual machines" or domUs, under a host operating system (dom0). Using Xen you can separate your applications into different virtual machines that are totally independent from each other (e.g. a virtual machine for a mail server, a virtual machine for a high-traffic web site, another virtual machine that serves your customers' web sites, a virtual machine for DNS, etc.), but still use the same hardware. This saves money, and what is even more important, it's more secure. If the virtual machine of your DNS server gets hacked, it has no effect on your other virtual machines. Plus, you can move virtual machines from one Xen server to the next one.
I will use Debain Sarge for both the host OS (dom0) and the guest OS (domU). In an additional section at the end I will also show how to create a virtual local network with virtual machines, with dom0 being the router.
-
- Login or register to post comments
Printer-friendly version
- 1951 reads
PDF version
More in Tux Machines
- Highlights
- Front Page
- Latest Headlines
- Archive
- Recent comments
- All-Time Popular Stories
- Hot Topics
- New Members
Events: Video Conferences, Code.gov, and LibreOffice
| GitLab Web IDE
|
Record Terminal Activity For Ubuntu 16.04 LTS Server
At times system administrators and developers need to use many, complex and lengthy commands in order to perform a critical task. Most of the users will copy those commands and output generated by those respective commands in a text file for review or future reference. Of course, “history” feature of the shell will help you in getting the list of commands used in the past but it won’t help in getting the output generated for those commands.
| Linux Kernel Maintainer Statistics
As part of preparing my last two talks at LCA on the kernel community, “Burning Down the Castle” and “Maintainers Don’t Scale”, I have looked into how the Kernel’s maintainer structure can be measured. One very interesting approach is looking at the pull request flows, for example done in the LWN article “How 4.4’s patches got to the mainline”. Note that in the linux kernel process, pull requests are only used to submit development from entire subsystems, not individual contributions. What I’m trying to work out here isn’t so much the overall patch flow, but focusing on how maintainers work, and how that’s different in different subsystems.
|
Recent comments
3 hours 55 min ago
3 hours 55 min ago
3 hours 57 min ago
7 hours 3 min ago
7 hours 15 min ago
14 hours 7 min ago
1 day 16 hours ago
1 day 17 hours ago
1 day 22 hours ago
2 days 23 hours ago