[mythtv-users] Virtualisation .. can it do this? (HP ProLiant MicroServer N40L)

Raymond Wagner raymond at wagnerrp.com
Tue Sep 25 15:56:32 UTC 2012


On 9/25/2012 08:18, Adrian Saul wrote:
> On 25/09/2012 9:10 PM, Damian wrote:
>>
>> One thing that constantly trips my up with Mythbuntu is
>> upgrading/updating it. I know a lot of you would say, if it's not
>> broke, don't fix it. But I like to have the latest stable version of
>> MythTV.
>>
>> So, my question is, could virtualisation help with this?
>>
>> When it's time for a big update, could I clone the working virtual
>> machine and keep it safe. Then update the 'copy' until I get that
>> working great. Then just delete the original version?
>
> Perfect example of the benefits of virtualisation.   I do sort of an
> awkward method of this, but use virtualbox to build my new Mythbuntu
> install, have a script/notepad file full of things to change on it, then
> copy it onto a new NFS root for my backend to run from.  Lets me do all
> the mucking around in a virtual setup and see what I need to do mostly
> before I put it into "production". Similar to my setup, you could
> snapshot things before you do an upgrade or just take snapshots for
> recovery points etc.

Incorrect. This is a side effect of virtualization, but not a benefit of 
virtualization. You can achieve the same exact behavior using nothing 
but `chroot`.

>>
>> Is that one of the points of having multiple virtual machines on the
>> server? Or is there another good reason to have it that I'm missing?
>
> Depending on the virtualisation software, you can move your VM images
> between physical machines during upgrades which saves you complete OS
> re-install.   You can also carve up test or play environments which you
> can throw away as well.  If you are running multiple OSes its a
> no-brainer as well to cut down on the number of boxes or use a single
> more powerful box for multiple tasks.

Binaries compiled for one version of the Linux kernel have no trouble 
running against any version of the Linux kernel, so long as it is the 
correct architecture, and they are not so far distant that important 
APIs have changed. On FreeBSD, you can even compile in backwards 
compatibility in the kernel to allow binaries from as far back as 4.x to 
run on a 9.x kernel. All you need to get right are the libraries, and 
`chroot` will do just fine in that regard.

If you are running multiple OSes, then it's a no-brainer to try to find 
software that all runs on a single OS to reduce your administrative load.

>>
>> If it is a good idea, how much harder am I making life for myself?
>> Baring in mind that I'm one of the dumb ones (meaning that I like a
>> GUI for everything! I can use the terminal minimally, but I'm always
>> scared of breaking something and have to cut and paste other peoples
>> instructions exactly).
> Well, as a professional sys admin the bane of my life is the cop out
> excuse of software vendors "we don't support X virtualisation" - without
> actually explaining what part of the virtualisation model their
> incredible software is able to violate that no others can.  If you get
> it going you might run into that if you have issues i.e first responses
> being "works for me outside virtualisation, must be that".   But other
> than that treat it as a learning opportunity - there are a lot of
> benefits to virtualisation and increasingly the old gaps in performance
> are disappearing.

As a professional sysadmin, you use virtualization for isolation. You 
want to combine multiple applications onto a single machine, but you 
don't want instability or insecurity on one application to risk 
affecting others, so you use virtual machines to isolate them as a 
measure against that. It's more cost effective to add the overhead and 
complexity of a full virtual machine than to perform an extensive 
analysis of the applications to determine whether you can risk letting 
the software run side-by-side. You may use it to allow live snapshotting 
and migration of an application that cannot be allowed to terminate for 
one reason or another. None of these reasons apply to a MythTV home user.



More information about the mythtv-users mailing list