Hi Markus, your emails are rejected by the list because you are sending them from a different email address you are not subscribed with. It sent you an invitation for the other email address. On Fri, 2015-02-20 at 09:17 +0100, Markus Helmke wrote: > Michel, i'm right with you. I've still some Ubuntu PV working, but > everything else I transverred to HVM and I can not mention that this > isn't felt slower than PV. On plus - Its easyer to handle things like > pci-passthrough. And on top there are spezial drivers, for example for > Windows they can be downloaded from Univention, which speeds up > Network- and Disk-Performance There are still some Benchmarks where pv > is working faster. Great that you can deliver some facts to my assumptions. The only downside I forgot to mention is that you will need a CPU that supports virtualization. I guess that nowadays nobody is using a processor that doesn't support that because they are slow and consume too much energy. -Michael > > > > > > > Viele Grüße, > > Markus Helmke > > Mail: markus(a)helmke.at > > > > -----Ursprüngliche Nachricht----- > > Von:Michael Tremer > > Gesendet: Fre 20 Februar 2015 02:05 > > An: R. W. Rodolico > > CC: documentation(a)lists.ipfire.org >> Wiki Mailingliste > > Betreff: Re: Xen Documentation > > > > Hi, > > > > On Tue, 2015-02-17 at 16:48 -0600, R. W. Rodolico wrote: > > > 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). > > > > All the hypervisors we have base on QEMU. VMware put it in their kernel. > > VirtualBox is still using userspace but have added lots of graphics > > features. The Xen project put it in a micro kernel. Of course lots of > > development has been put in all of these projects and therefore they > > diverged a lot. > > > > > 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. > > > > I think that we should have a short mentioning that the HVM version is > > the preferred one then. It is actually not that much slower any more. > > CPUs do everything in regards of their jobs. Some devices needs to be > > emulated which causes a bit more overhead yes. In perspective though > > IPFire does not read or write a lot of data from/to disk so that there > > will never be a bottleneck on that end. The virtual network drivers have > > also a negligible overhead. > > > > The PV approach comes with way more difficulties and I guess that HVM is > > most used any way. > > > > > 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. > > > > Maybe someone else can contribute this later. > > > > > > > > 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 > > > >> > > > > > _______________________________________________ > > Documentation mailing list > > Documentation(a)lists.ipfire.org > > http://lists.ipfire.org/mailman/listinfo/documentation > >