On Jan 31, 2012, at 3:16 PM, DJ Lucas wrote:
> On 01/31/2012 10: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.
>>
>> -- Bruce
>
> Note: I'm not gonna fight for or against VB, just throwing out the two
> known selling points as requested. I could happily use QEMU for my
Right. I, too, am trying to avoid the debate of A vs B.
> There are a couple of advantages with VB, but it really depends on your
> needs. One cool feature of VB is that it provides remote console access
> without installing a dedicated management program.
I just spent some time looking into KVM. It appears to a be a full-virt system
that uses HVM instruction set support to get para-virt I/O performance.
There's another key difference in that KVM has a Type-2 Hypervisor; i.e., the
Linux kernel runs "underneath" (i.e., closer to the bare-metal) KVM. The
hypervisor is "hosted".
Xen (along with other systems, like VMware) has a Type-1 Hypervisor; i.e., Xen
itself runs on the bare metal. As such, it requires specific management
utilities. Though, management utilities are required with *any* hypervisor; I
think DJL was asking whether or not you need those utilities to gain access to
the machine.
In Xen, you "attach" a console to a running VM. That attachment does require
the management utilities. For console-based OSes (e.g., Linux) this means very
little; it's a bit like opening an SSH connection. For graphical OSes, it
requires more support--and you have to build the X11 tools. However, I don't
see that as a good or bad...I only use SSH-enabled Guests (and don't have
Guests that have graphical consoles).
In my personal use, I tend to think that the inclusion of X-based tools is a
drawback--I tend to use virt systems to run server clusters that don't have
graphical UI requirements. But, if you're hosting Windows or X11-based Linux
systems, my flavor of Xen is likely to be more work to setup.
> Does Xen or QEMU bring a GUI management tool of any sort?
AFAIK, Xen does have a set of X11 tools, but I'm not sure how well-geared they
are for a casual user.
The Xen management tools are pretty mature; they would have to be, with huge
users like Amazon for their EC2 cloud. They're undergoing some changes right
now, for even better performance, so I don't know what the exact state of the
tools are; suffice it to say, they're pretty robust for an enterprise
deployment. I couldn't make a statement one way or the other about desktop
users. Xen does have a bit of a reputation for being harder to setup, since
it's a Type 1 Hypervisor.
> another point for VB I guess, as well as the two above. Free Xen Server
> used to have a limit where you couldn't use multiple physical NICs, I
> unfortunately do not know anything about the open source variant, I've
I'm not aware of this physical limit, though I've never tried exceeding it. My
cluster only has machines with up to 5 NICs, and I support dozens of virtual
network IFs.
At the moment, there's a large body of support and activity for both Xen and
KVM. They are both in the mainline kernel (as of 3.0), which means supporting
both "out-of-the-box" is more feasible. Xen takes more work setting up
(though, that's just editing your GRUB conf files). KVM may be easier to
deploy for graphical Guests; I've never tried hosting one on Xen.
I'm not really trying to recommend one over the other (it appears to be a
rather religious "Emacs/Vi" issue for those who care). My personal opinion is
just that Xen would be a nice add to BLFS. Although, frankly, I'm not married
to the idea. I know Bruce's intentions for BLFS in general are a little
divergent from my needs. I'm content with Xen being a consumer of the BLFS
dependencies it has, and to offer some feedback about those dependencies (e.g.,
bridge-utils).
Speaking of which--has anyone successfully compiled Dev86 on their BLFS
setup...?
Q
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
