On Jan 31, 2012, at 1:26 PM, Bruce Dubbs wrote:
> Qrux wrote:
>> On Jan 31, 2012, at 8:58 AM, Bruce Dubbs wrote:
>
>>> What are the advantages/disadvantages of VB over Xen and KVM? If it
>>> doesn't add any significant capabilities, I don't see the effort to make
>>> it fit into BLFS as useful.
>>
>> I think there are a couple of core considerations to distinguish virt
>> systems:
>>
>> * Whether it uses full-virtualization or paravirtualization.
>> * The dependencies (including the need for multilib systems)...
>> * ..and the context for those dependencies.
>
> I can understand what full-virtualization is, but I'm not sure what
> paravirtualization is. Why would you choose one or the other.
I am not a Xen developer. Or a VM developer. But, I do understand what
para-virt is conceptually, so I'll provide a high-level answer and let the
implementation folks pick apart the details. ;)
A para-virt Guest is (typically) a "Modified Guest OS"; i.e., the Guest OS
needs to replace its syscalls. So, instead of the Guest syscalls calling down
into the hardware--i.e., instead of executing the maching instructions that
would normally come as a result of calling the syscall--the syscalls of a
para-virt Guest are calls into an "API" that's exported by the para-virt Host
OS.
Before anyone panics with: "Holy crap--you have to patch the kernel for
PV?"...No, that's no longer necessary. As of Linux 3.0, PV support
(paravirt-ops) is built into the kernel. Historically, there were gnarly
patches to the kernel, and you had to be a wizard to get things working (unless
you ran a commercial Xen distro like SuSE or Oracle or Citrix stuff). Now,
it's just a matter of setting a few kernel CONFIG parameters.
As such, PV Guests include drivers, too, which also call down into a driver API
exported by the PV Host. AFAICT, para-virt came up because x86 platforms are
hard to virtualize efficiently; i.e., to achieve it, historically, you had to
provide a complete emulation layer that would intercept all the machine
instructions. PV is a way to achieve virtualization without a full emulation
stack, and have the benefit, then, of being able to run at native (or
near-native) speed. The downside, in order to run Guests inside the para-virt
system, they have to be ported to replace their syscalls.
The upside, of being fast, is quite real. Since they don't require any
emulation like a full-virt system would provide, application codes runs
directly on the CPU, and system calls simply call down into the Host. Then,
the Host executes the para-virt system call--at native speed--on behalf of the
Guest. Since the Host handles already handles multiprocessing-capable hardware
access, having multiple Guests call into the syscall interface doesn't create
any special architectural considerations; it simply requires that the Host be
able to schedule Guests.
But these performance considerations may be somewhat historical. With the
release of HVM and the Intel VT-x or AMD-V instructions for hardware access,
I'm not sure how every virt system is classified, and how whether it's PV, HVM,
or FV. Or, if there are other shades of gray with respect to drivers.
For me, I chose para-virt because it's fast--and because I don't need access to
unmodified Guest OSes (like Windows). I also don't need my guests to have
hardware access...
>> For Xen:
>>
>> * It has both full-virt and paravirt capabilities.
>> * It *can* require gnarly 32-bit multilib dependencies for 64-bit
>> systems...
>> * ...when you want full-virt or hardware-passthrough on 64-bit systems.
>>
>> That last bit is what I meant by "contextual dependencies". For
>> example, I only run Xen with 64-bit Linux Guests on a 64-bit Linux
>> Host without hardware-passthru. So, I'm not affected by the 32-bit
>> multilib dependencies at all. So, in my case, I've been able to
>> build a 64-bit-only Xen system on LFS-7.0 with bridge-utils as the
>> only dependency.
>
> By host hardware-passthru, I take it you mean things like CD-ROM or
> audio cards.
I meant PCI-passthru. IDK how it works; I don't use this capability. I assume
it makes use of the HVM instruction set somehow.
>> For Xen, the gnarly 32-bit/multilib dependencies mostly seem to come
>> from either full-virt or hardware-passthru related features.
>>
>> I can't say I know what the package selection criteria is for BLFS
>> (and no, I'm not starting that debate again right now). But to
>> answer Andrew's question--yes, I think we should consider including
>> any virt system in BLFS if it's "relatively easy" to whittle down the
>> "contextual dependencies" as far as is practical (e.g., not needing
>> to build a multilib system just to get your virt system running).
>
> You know I added kvm-qemu to BLFS a couple of days ago, right?
Yep. :) You mentioned it last time. I wasn't questioning kvm/qemu. I just
meant that I think Xen should be considered because it can--under some Guest
constraints like not needing to run Windows or some other unmodified
Guest--have very modest dependencies.
This looks interesting (Xen vs KVM):
http://iopscience.iop.org/1742-6596/219/4/042005/pdf/1742-6596_219_4_042005.pdf
And I'll look into KVM more.
Q
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
