So have a nice Easter-Time ...

Viele Grüße,

Markus Helmke

Mail: markus@helmke.at <mailto:markus@helmke.at>

 
 
-----Ursprüngliche Nachricht-----
> Von:R. W. Rodolico <rodo@dailydata.net>
> Gesendet: Die 17 Februar 2015 23:48
> An: documentation@lists.ipfire.org >> Wiki Mailingliste <documentation@lists.ipfire.org>
> Betreff: Re: Xen Documentation
> 
> 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@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
> _______________________________________________
> Documentation mailing list
> Documentation@lists.ipfire.org
> http://lists.ipfire.org/mailman/listinfo/documentation
>