[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