[mythtv-users] Back-end Virtualization
Raymond Wagner
raymond at wagnerrp.com
Fri May 11 15:51:25 UTC 2012
On 5/9/2012 21:22, Nathan Hawkins wrote:
> Is ‘Anyone’ virtualizing their backend?! I cant believe I’m the only
> person out there who wants to do this…
I've stated my views on virtualization on this mailing list multiple
times in the past, but new people keep joining and asking, so here goes...
Why do you want to want to virtualize your backend? "Because I think it
would be interesting" is a perfectly valid reason here. "Because the
industry uses it and VM vendors tell me it magically makes everything
better" is not. So why does industry use it?
The first reason would be security. There are many mechanisms to
isolate different processes on a single system, but none of them can be
as complete or absolute as full system virtualization. You can run
different application servers, or servers for multiple departments with
different user access rights on one physical system, and if one gets
compromised, there is (almost) no risk to the rest. It can be flushed
and restored from a clean copy with no harm to the other services. If
you are looking to virtualize MythTV for security purposes, your journey
ends here. If you are not running MythTV on a safe, trusted network,
you either shouldn't be running MythTV, or you should be looking into
adding cryptographic authentication into all the various communication
interfaces MythTV uses.
The second reason is high availability. The virtual machine allows you
to save the state of the machine, and in the event of a failure, resume
that state on another piece of hardware. This is really only a crude
route to high availability, as such capability is much more effectively
and efficiently performed by the application itself, such as MySQL
clustering and replication servers. It becomes a question of how
valuable is the application to your needs, and is it valuable enough to
warrant the time and expense developing native support in the
application. If your interest is in HA, you've already thrown far more
money at virtual machines than someone who would be asking a basic
question such as this on an open source mailing list.
And that's it. Those are the two good reasons to run virtual machines
in a production environment.
-- Counter Argument 1 --
What about the need to run on a different hardware architecture or
operating system? Don't. Find software that suits your needs that can
all run on one OS. If it's something critical that you cannot do
without, perhaps that makes it worth dedicating another machine to.
-- Counter Argument 2 --
What about software that refuses to run on anything outside a
pre-defined hardware set, so you define it against a virtual machine to
allow the VM to be mobile? Shame on the company for putting such
restrictive licensing measures on their software. Double shame for
botching it in such a manner that it could be bypassed by simply using a
VM. From an idealist standpoint, shame on the customer for patronizing
such an abusive developer.
-- Counter Argument 3 --
What about software that could crash and take out a system? If you're
doing development, this is a great thing. Any application that you
expect to crash with destructive results should not be used in a
production environment.
-- Counter Argument 4 --
What about ease of management? When trying to run multiple applications
and servers on a single system, you may run into dependency conflicts.
You may update one library for one application, only to find it has
broken another application. Virtual machines let you run multiple
independent installs, with independent dependency sets, to avoid these
issues. This is the big one, and I believe the reason most people
improperly use virtual machines.
This has NOTHING TO DO with virtualization. Virtual machines require
this behavior, but this behavior does not require virtual machines. You
can do the SAME EXACT THING with a simple chroot, without all the
unnecessary complexity and overhead of running a fully virtualized
hardware instance. All your required libraries would be in the
self-contained chroot. The only thing you would have to match for
binary compatibility moving from one machine to the next to the next is
the kernel interfaces, and those interfaces retain backwards
compatibility for a long time. If you really wanted, you could even
implement these on opaque disk images, that would get loopback mounted
where ever you wanted to run them, just like virtual machines.
More information about the mythtv-users
mailing list