public inbox for documentation@lists.ipfire.org
 help / color / mirror / Atom feed
From: "R. W. Rodolico" <rodo@dailydata.net>
To: documentation@lists.ipfire.org
Subject: Re: Xen Documentation
Date: Tue, 17 Feb 2015 16:48:33 -0600	[thread overview]
Message-ID: <54E3C541.1050407@dailydata.net> (raw)
In-Reply-To: <1424189149.17826.130.camel@ipfire.org>

[-- Attachment #1: Type: text/plain, Size: 5752 bytes --]

FYI, a brief (and hopefully accurate) reply to your questions.

paravirtualization (PV) uses the kernel from the underlying DOM0 (the OS
running on the bare machine, which runs everything else).

Hardware virtualization (HVM) is completely divorced from the underlying
operating system. Instead, it uses its own kernel and some fake hardware
exported by the underlying system.

PV's are much faster since one kernel controls everything. The kernel is
able to direct resource usage without any intermediate layer. However,
you must keep the virtual and the underlying system in sync. One thing I
remember is every time you upgrade the kernel on the DOM0, you must copy
the new lib's to every virtual. Obviously, you can not run non-Linux
systems on a PV. To move a PV from one DOM0 to another, the kernel's and
libraries must match, or you need to copy the libraries to the virtual
before running it.

HVM's have a layer between them and the underlying kernel. I think that
is QEMU, but I don't remember. Since it has to go through a second
translation layer, it uses more resources. However, you can have a 2.4
kernel on the DOM0, and be running the latest kernel on the virtual, or
even Windows, BSD or OSX. HVM's can be moved between DOM0's with little
or no modification (generally a small line in the config file).

For IPFire, I prefer HVM's because you have spent so much time making
sure the kernel and libraries are secure. Thus, even on an older DOM0, I
can have a very secure firewall/router. However, some things such as
automated shutdown of the IPFire instance are not available since IPFire
does not include the HVM device drivers (they use a generic device
driver when IPFire is installed). That can cause a problem during server
shutdown, since the backup is to "destroy" the virtual, ie pull the plug.

As far as I know, tying a physical piece of hardware to a single DOMU is
still supported, though I have not used that since 3.x,
http://wiki.xenproject.org/wiki/XenPCIpassthrough indicates it is still
available.

Rod

On 02/17/2015 10:05 AM, Michael Tremer wrote:
> Hi,
> 
> if I may send you a little wishlist:
> 
> There are many many guides about how to set up a Xen server with Debian.
> I am not sure about the state of all of them. Some of them are based on
> outdated versions of Debian. I suppose it is best to merge them all
> together and delete the rest.
> 
>   http://wiki.ipfire.org/start?do=search&id=xen
> 
> Maybe it is a good idea to start a little virtualisation section
> (http://wiki.ipfire.org/en/virtualization/start) with subsections for
> Xen (http://wiki.ipfire.org/en/virtualization/xen/start), KVM and all
> the rest.
> 
> Explaining an installation of the IPFire system from scratch should not
> be necessary but the differences to using Xen should be pointed out
> somewhere.
> 
> I personally am always confused about the HVM and PV thing. What should
> people use? What are the advantages/disadvantages?
> 
> There was also this:
> 
> http://planet.ipfire.org/post/dropping-support-for-xen-3-x-deprecation-warning
> http://planet.ipfire.org/post/bye-bye-xen-legacy-kernel
> 
> Many people use the feature where you can hand over the physical
> hardware to the guest machine. Does this actually still work? What are
> the benefits of that?
> 
> All this information should be out there somewhere in the wiki. Putting
> it all together in a nice section with small pages which are easy to
> find would be really great :)
> 
> -Michael
> 
> On Tue, 2015-02-17 at 03:10 -0600, R. W. Rodolico wrote:
>> David,
>>
>> It would be great if you could get some notes on this. Even if they are
>> rough, it would be better than nothing. Having never messed with KVM
>> (I'm Debian/Xen for the most part), I really don't know much about it,
>> though I do engage in "religious wars" over KVM vs Xen vs Virtual Box
>> with from friends/associates of mine.
>>
>> Anyway, if you had some brief notes, it would be great to include them.
>>
>> Rod
>>
>> On 02/16/2015 11:07 PM, David J. Allen wrote:
>>> On 02/16/2015 08:11 PM, R. W. Rodolico wrote:
>>>> I am in the process of creating documentation for a Xen virtual IPFire
>>>> install. If anyone else is doing it also, please let me know so we can
>>>> collaborate. I'm hopeful to have it complete Friday 20 Feb.
>>>>
>>>> I am trying an install using the scon image. Assuming that works, should
>>>> I also write documentation on how to do it from a standard "installer"
>>>> installation?
>>>>
>>>> Again, if anyone else is doing this, please let me know so we do not
>>>> duplicate efforts.
>>>>
>>>> Rod
>>>
>>> I am not writing docs on doing so* but I have been running Ipfire in a
>>> VM under KVM on Scientific Linux 6.x for a couple of years now. I think
>>> setting up Ipfire was easier than getting the KVM set up right.
>>>
>>> The VM host box has 2 onboard NICs, but I'm using a dual-NIC card in the
>>> box which is dedicated to the Ipfire VM. The tricky part was figuring
>>> out how to give Ipfire exclusive access to the WAN NIC without it being
>>> accessible to the KVM host and the other VM guests.
>>>
>>>
>>> * Although I should do it at least for myself - had to redo my
>>> installation a while back after moving and had left no notes for myself.
>>> Which of course resulted in re-inventing my own wheel! ;)
>>>
>>>
>>> _______________________________________________
>>> Documentation mailing list
>>> Documentation(a)lists.ipfire.org
>>> http://lists.ipfire.org/mailman/listinfo/documentation
>>

-- 
"Rod" Rodolico
Daily Data, Inc.
POB 140465
Dallas TX 75214-0465
214.827.2170
http://www.dailydata.net

  parent reply	other threads:[~2015-02-17 22:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-17  4:11 R. W. Rodolico
2015-02-17  5:07 ` David J. Allen
2015-02-17  9:10   ` R. W. Rodolico
2015-02-17 16:05     ` Michael Tremer
2015-02-17 21:34       ` R. W. Rodolico
2015-02-17 22:48       ` R. W. Rodolico [this message]
2015-02-20  1:04         ` Michael Tremer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54E3C541.1050407@dailydata.net \
    --to=rodo@dailydata.net \
    --cc=documentation@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox