Re: xen bootcamp (was: xen: was Challenge to you: Voice your concerns regarding systemd) upstream
Hi.
On Wed, Oct 01, 2014 at 09:55:47AM -0400, Steve Litt wrote:
> > Xen is a microkernel, and there's two major versions of such
> > microkernel
> > - 3 and 4. Debian currently uses version 4, about the only one who
> > uses version 3 today is Oracle. Xen's microkernel is a free software.
> >
> > But there's more to that as there's Xen's API made for controlling
> > domUs, in fact, there's two sets of Xen's API - xm (made by human
> > beings for human begins), and its successor xl (made by our friends
> > from Mars for robots). Again, Xen's API is a free software.
> >
> > But using Xen's API directly is not the thing that Joe the average
> > admin would do. Hence, there're tools which use Xen's API:
> >
> > - venerable xm toolset
> > - hipster xl toolset
> > - RedHat's pet libvirt
> > - that thingie they put into XenServer
> > - an abomination they put into OracleVM
> > - that secret thing they in at Amazon
> >
> > Hence a choice of distribution depends on a Xen toolset of choosing
> > and a huge portion of a personal taste.
>
> So what do you think of the toolset that comes with Debian?
They don't give you xm anymore. Pain, horror, sadness and all that. I
miss Debian etch.
xl is ok, as long as you don't have to use it directly. Dealing with
UUIDs is something I prefer to avoid unless I'm paid to do so.
libvirt is in a good shape in both stable and backports, and has very good
maintainer team. Upstream are reasonable guys too. A personal experience
for both.
The usage of libvirt has the following caveats:
1) One *must* be prepared to editing xml in a text editor.
Justification - it's the only way of uncovering most libvirt
possibilities. Avoid anything that's built on libvirt like plague,
unless you're happy with GNOME 3.
2) One *must* be prepared to stomach a typical Red Hat userspace product.
I.e. it's enterprisey, it expects a typical Red Hat's userland
(OpenBSD's netcat is a requirement, for example). As a typical Red Hat's
userland it has its share of integration with dbus and
that-not-shall-be-named-pid1-process. Integration is optional, as far as
stable is concerned.
3) One *must* be prepared to funny libvirt's habits to touch the most
unusual parts of server's setup.
I.e. libvirt's own set of iptables rules? Check.
Creating own bridges? Check.
Trying to manage said bridges with own set of ebtables rules? Check.
Trying to create own cgroup sets just for the fun of it? Check.
Did I mention that it's all configured via XML?
Most of the annoying stuff can be disabled (or worked around), but it
has to be done.
Still, while libvirt can give you a load of trouble - accept no
substitutes.
> Hypothetically, if you were a person who hated the concept of systemd,
> in the case of using Debian for dom0 and dom0 only, with no X, would
> you care whether or not the dom0 initted from systemd?
If I was such person, I would take all steps nessesary to remove said
init system from the dom0. Because, hate is irrational.
But, since I'm a different person (I only hate carefully chosen humans,
not software :) - I can tolerate any init as long as it does not
jeopardize boot, shutdown and reboot processes.
Especially because I don't boot, shutdown or reboot servers often.
> At that point,
> isn't the Linux distro just a well-segregated piece of xen dom0?
Yes and no. There're things you do differently in dom0 comparing to the
run-of-the-mill server. Time synchronizing comes to the mind
immediately. Monitoring CPU, IO and memory come second.
But, for the most part it's still the usual 'apt-get update && apt-get
upgrade' routine. Barring the initial setup process, of course.
> > > To my way of thinking, the dom0 OS isn't really being used as an OS
> > > at all: It's just an enabler for xen, and to my way of thinking,
> > > that means it has way fewer challenges than a normal OS. So if it
> > > uses systemd, so what? It's not like you have to worry about
> > > running Gimp or Gnome or KDE or various authentication facilities
> > > directly on it: It's a vehicle for xen, no more, no less.
> >
> > On a typical virtualization server - yes, dom0 is used for managing
> > domUs, and not much more.
> >
> > But, if you need to run X - things are very different, as you use dom0
> > as a conventional PC. Because - it's *very* difficult to force Xen to
> > transfer control of your video card to domU. Possible, but very
> > difficult, and hardware specific.
>
> All I know of xen is what I've overheard in discussions and seen in
> that one guy's presentation, but my impression was that the way to use
> xen is to have xen on a server and access its domU guest OS's on a
> client machine. Is that true?
That's one way to do it. domU is basically indistinguishable from the
real server as long as you're talking to it via the network only.
But, there're people who view a virtualization as a way to install a
certain non-free OS (with funny four-colored banner logo), isolate
it from the outside world, and use said non-free OS to run all kinds of
non-free games. And said non-free games usually require 3D acceleration.
Hence, there's a need for hypervisor to be able to provide domU with an
arbitrary piece of a real hardware (video card, for example).
An equivalent from the free software world is the possibility of
running, say, GNOME3 or venerable Compiz with all the bells and whistles
in a domU.
There's a need for this in a server world too - I/O behaves much better
once you provide domU with a real HBA instead of forcing domU to go all
those emulation loops.
> > > I went to a Xen talk, and as I remember the guy said Xen is
> > > developed and tested on Ubuntu, so that's your best bet. Yeah,
> > > Ubuntu will have systemd, but if it works for the xen people, it
> > > should work for us all.
> >
> > That guy does not seem to know what he's talking about. Xen is
> > developed by Xen Project (xen.org), Citrix and Oracle (they like to
> > say so, at least). Ubuntu merely builds Xen from the source, as
> > others do.
>
> I probably heard wrong or interpreted wrong. The guy seemed very
> knowledgeable, not just to me, but to the other hundred or so people in
> the room who were asking lots of questions. It's probable I just got
> confused.
xen.org seems to think otherwise :) In a discussion like this I prefer
to listen to the upstream, not the downstream.
> [snip netBSD stuff]
> >
> > > Unless I'm vastly misinformed, once your dom0 xen is installed, you
> > > can now install domU hosts of any type you want, with or without
> > > systemd, and use them to your heart's content.
> > >
> > > Am I understanding the situation right?
> >
> > Yes, that's correct. To run so called 'fully virtualized OS' (i.e. not
> > modified to work with Xen) you'll need to have Intel VT-d CPU flag (or
> > an appropriate AMD equivalent), but that's all that required.
>
> Isn't that VM support built into all desktop mobo/CPU systems built in
> the last 3 years?
Haha. Nope. Some vendors disable VT-d to play market segmentation.
Sometimes one can unlock it, sometimes it's impossible. It's better for
the self-assembled PCs, worse for the brand PCs, really horrible for the
laptops.
Besides, VT-d only allow you to pull 'running fully-virtualized domUs'
trick. To pull 'provide a hardware to domU' trick you need IOMMU-capable
motherboard, and those are rare on a consumer hardware market.
> > Convincing domU to use a real hardware is entirely different story.
>
> Personally, I wouldn't want to use real hardware, for much the same
> reason as my objections to systemd: Modularity. If I'm going to use xen
> as a layer beneath my (perceived) OS, I want all my calls to go to that
> layer, not the hardware beneath it. Unless, of course, there's a huge
> performance advantage kind of like the DOS days when you wrote to B800
> instead of using the BIOS write to screen, in order to speed up screen
> write by a factor of five or ten. But my understanding is that if the
> machine with dom0 has VM speedup built into the CPU/mobo, it goes fast
> enough.
>
> Just one more question: What's your opinion of Debian as a vehicle to
> deploy a xen dom0?
It'll work. That's a good thing in my book, as there're distributions
where Xen should be forced to work, and there're ones where Xen needs
user-placed carefully weighted kludges implemented just for the sake of
running Xen. No examples, that's intentional.
There might be no enterprise-grade management interface (and no,
virt-manager is not a enterprise-grade one), but it'll be OK for the
home server or SOHO.
Please note that I haven't seen jessie's Xen so far. Because - Xen does
not tolerate rushing.
Reco
Reply to: