Basic Server for running 2 Seperate virtual machines

[Njordic]

Hey guys,

Got a quick question, I've recently built a small and inexpensive plex server and I want another server to do basic tasks but it needs two operating systems. Is there anything you'd recommend? Also I was thinking ITX because I want the footprint to be minimal. 

[samcool55]

Well that depends what kind of VM's you want to run.

With VM's it's usually RAM that becomes quickly an issue.

[jde3]

VM's over provision the ram the system actually needs a lot of the time. Have you considered containers? They don't work for everything but are much much more efficient.

 

(FreeBSD Jails are awesome)

[lacion]

what exactly do you need, details will make it easier to recommend solutions.

 

i personally run everything in docker using a server and a small barebones, its a lot of things running but i use this for local development and just my house, the plex container has the gpu attached to it for transcoding. i can do 4k no problem.

 

kubectl get pods --all-namespaces
NAMESPACE        NAME                                                   READY     STATUS
databases        kubedb-67cf5fbccc-kjjqv                                2/2       Running
databases        pgadmin4-0                                             2/2       Running
databases        postgres-0                                             2/2       Running
databases        redis-0                                                2/2       Running
elasticsearch    elasticsearch-86d9589bc5-8ljjp                         1/1       Running
home             openhab-98cd7c998-wcxjb                                1/1       Running
kibana           kibana-ffb9ddd54-7w6lc                                 1/1       Running
kube-system      coredns-65dcdb4cf-2dwrm                                1/1       Running
kube-system      etcd-kubemaster                                        1/1       Running
kube-system      filebeat-mmmhl                                         1/1       Running
kube-system      filebeat-vs9lp                                         1/1       Running
kube-system      heapster-549fb5b47f-ts4wg                              1/1       Running
kube-system      kube-apiserver-kubemaster                              1/1       Running
kube-system      kube-controller-manager-kubemaster                     1/1       Running
kube-system      kube-proxy-h2f8m                                       1/1       Running
kube-system      kube-proxy-n25n8                                       1/1       Running
kube-system      kube-scheduler-kubemaster                              1/1       Running
kube-system      tiller-deploy-5b48764ff7-krwvr                         1/1       Running
kube-system      weave-net-t4l8z                                        2/2       Running
kube-system      weave-net-tdtgr                                        2/2       Running
logstash         logstash-67657bd5b8-vvz6w                              1/1       Running
media            jackett-58f5fdbbb6-x76kz                               1/1       Running
media            plex-569dcdbb9b-gx8vb                                  1/1       Running
media            radarr-74959d5585-gd44h                                1/1       Running
media            sonarr-668d84cc78-xmtb4                                1/1       Running
media            transmission-5c67f8bc67-lpvhh                          1/1       Running
metallb-system   controller-657f96d7dc-lhscp                            1/1       Running
metallb-system   speaker-p26xh                                          1/1       Running
metallb-system   speaker-t59tq                                          1/1       Running
monitoring       alertmanager-kube-prometheus-0                         2/2       Running
monitoring       kube-prometheus-exporter-kube-state-6cfcc866f7-64ljf   2/2       Running
monitoring       kube-prometheus-exporter-node-dvq24                    1/1       Running
monitoring       kube-prometheus-exporter-node-qhcng                    1/1       Running
monitoring       kube-prometheus-grafana-f9cf44f9c-494rb                2/2       Running
monitoring       prometheus-kube-prometheus-0                           2/2       Running
monitoring       prometheus-operator-6f57fb444d-sgnj4                   1/1       Running
rook-system      rook-agent-9wflt                                       1/1       Running
rook-system      rook-agent-t84sv                                       1/1       Running
rook-system      rook-operator-77cf655476-bsgxf                         1/1       Running
rook             rook-api-6698c77f5d-vclr9                              1/1       Running
rook             rook-ceph-mgr0-6b5864fc4f-hcdfs                        1/1       Running
rook             rook-ceph-mon0-pb7s5                                   1/1       Running
rook             rook-ceph-osd-bvrfw                                    1/1       Running
tools            gogs-gogs-845c9bfcfc-gf55j                             1/1       Running
tools            jenkins-5fb757c7fb-m6g4p                               1/1       Running
tools            locust-master-84dd9d868b-ps6dt                         1/1       Running
tools            locust-worker-b66c9894c-mfqhr                          1/1       Running
tools            locust-worker-b66c9894c-xzcng                          1/1       Running
tools            registry-docker-registry-proxy                         1/1       Running
tools            registry-docker-registry-private                       1/1       Running
weave            kube-state-metrics-5987f5944d-2924z                    1/1       Running
weave            prometheus-575d4d4fcd-m4fg4                            2/2       Running
weave            weave-agent-594cb4865b-njcqb                           1/1       Running
weave            weave-flux-agent-55d7ff76f8-4rjnb                      1/1       Running
weave            weave-flux-memcached-69d58967d6-jkqbl                  1/1       Running
weave            weave-scope-agent-79dfs                                1/1       Running
weave            weave-scope-agent-tgg9r                                1/1       Running

if anyone is interested most of the definitions for this stuff is here https://github.com/lacion/k8s_homelab

[Njordic]

13 minutes ago, jde3 said:

VM's over provision the ram the system actually needs a lot of the time. Have you considered containers? They don't work for everything but are much much more efficient.

 

(FreeBSD Jails are awesome)

What do you mean by containers? I'm a bit new and not well versed in Virtual Machines, sorry and Thank You

[Njordic]

6 minutes ago, lacion said:

what exactly do you need, details will make it easier to recommend solutions.

 

i personally run everything in docker using a server and a small barebones, its a lot of things running but i use this for local development and just my house, the plex container has the gpu attached to it for transcoding. i can do 4k no problem.

 

kubectl get pods --all-namespaces
NAMESPACE        NAME                                                   READY     STATUS
databases        kubedb-67cf5fbccc-kjjqv                                2/2       Running
databases        pgadmin4-0                                             2/2       Running
databases        postgres-0                                             2/2       Running
databases        redis-0                                                2/2       Running
elasticsearch    elasticsearch-86d9589bc5-8ljjp                         1/1       Running
home             openhab-98cd7c998-wcxjb                                1/1       Running
kibana           kibana-ffb9ddd54-7w6lc                                 1/1       Running
kube-system      coredns-65dcdb4cf-2dwrm                                1/1       Running
kube-system      etcd-kubemaster                                        1/1       Running
kube-system      filebeat-mmmhl                                         1/1       Running
kube-system      filebeat-vs9lp                                         1/1       Running
kube-system      heapster-549fb5b47f-ts4wg                              1/1       Running
kube-system      kube-apiserver-kubemaster                              1/1       Running
kube-system      kube-controller-manager-kubemaster                     1/1       Running
kube-system      kube-proxy-h2f8m                                       1/1       Running
kube-system      kube-proxy-n25n8                                       1/1       Running
kube-system      kube-scheduler-kubemaster                              1/1       Running
kube-system      tiller-deploy-5b48764ff7-krwvr                         1/1       Running
kube-system      weave-net-t4l8z                                        2/2       Running
kube-system      weave-net-tdtgr                                        2/2       Running
logstash         logstash-67657bd5b8-vvz6w                              1/1       Running
media            jackett-58f5fdbbb6-x76kz                               1/1       Running
media            plex-569dcdbb9b-gx8vb                                  1/1       Running
media            radarr-74959d5585-gd44h                                1/1       Running
media            sonarr-668d84cc78-xmtb4                                1/1       Running
media            transmission-5c67f8bc67-lpvhh                          1/1       Running
metallb-system   controller-657f96d7dc-lhscp                            1/1       Running
metallb-system   speaker-p26xh                                          1/1       Running
metallb-system   speaker-t59tq                                          1/1       Running
monitoring       alertmanager-kube-prometheus-0                         2/2       Running
monitoring       kube-prometheus-exporter-kube-state-6cfcc866f7-64ljf   2/2       Running
monitoring       kube-prometheus-exporter-node-dvq24                    1/1       Running
monitoring       kube-prometheus-exporter-node-qhcng                    1/1       Running
monitoring       kube-prometheus-grafana-f9cf44f9c-494rb                2/2       Running
monitoring       prometheus-kube-prometheus-0                           2/2       Running
monitoring       prometheus-operator-6f57fb444d-sgnj4                   1/1       Running
rook-system      rook-agent-9wflt                                       1/1       Running
rook-system      rook-agent-t84sv                                       1/1       Running
rook-system      rook-operator-77cf655476-bsgxf                         1/1       Running
rook             rook-api-6698c77f5d-vclr9                              1/1       Running
rook             rook-ceph-mgr0-6b5864fc4f-hcdfs                        1/1       Running
rook             rook-ceph-mon0-pb7s5                                   1/1       Running
rook             rook-ceph-osd-bvrfw                                    1/1       Running
tools            gogs-gogs-845c9bfcfc-gf55j                             1/1       Running
tools            jenkins-5fb757c7fb-m6g4p                               1/1       Running
tools            locust-master-84dd9d868b-ps6dt                         1/1       Running
tools            locust-worker-b66c9894c-mfqhr                          1/1       Running
tools            locust-worker-b66c9894c-xzcng                          1/1       Running
tools            registry-docker-registry-proxy                         1/1       Running
tools            registry-docker-registry-private                       1/1       Running
weave            kube-state-metrics-5987f5944d-2924z                    1/1       Running
weave            prometheus-575d4d4fcd-m4fg4                            2/2       Running
weave            weave-agent-594cb4865b-njcqb                           1/1       Running
weave            weave-flux-agent-55d7ff76f8-4rjnb                      1/1       Running
weave            weave-flux-memcached-69d58967d6-jkqbl                  1/1       Running
weave            weave-scope-agent-79dfs                                1/1       Running
weave            weave-scope-agent-tgg9r                                1/1       Running

if anyone is interested most of the definitions for this stuff is here https://github.com/lacion/k8s_homelab

Well I currently have an ITX running Plex but I have two old Optiplex's running media management and grabbing things from RSS, but I want too run to operating systems to minimize my physical footprint.

[Njordic]

17 minutes ago, jde3 said:

VM's over provision the ram the system actually needs a lot of the time. Have you considered containers? They don't work for everything but are much much more efficient.

 

(FreeBSD Jails are awesome)

Does that mean I do need a fast CPU, can I survive on an old H2 socket?

[samcool55]

2 minutes ago, Njordic said:

What do you mean by containers? I'm a bit new and not well versed in Virtual Machines, sorry and Thank You

https://www.sdxcentral.com/cloud/containers/definitions/containers-vs-vms/

It basically removes the overhead caused by running a full vm for each scenario.

If you need 5 vm's for each a specific function, you need for example 5 Server 2016 machines, and instead of running 5 you only run 1 while keeping all the services apart so you can add and remove them if you like.

[jde3]

A container is virtual server that shares the hosts cpu, ram and disk storage. It's similar to a VM but it does not run a different OS.

 

They work a little differently depending on what your using but in FreeBSD's case a jail would give you a root and look an smell like it's own computer but it would share the resources of the host system instead of you provisioning set resources. (tho that can be done too)

 

Docker is a type of container, namespace and cgroups.

[Njordic]

1 minute ago, samcool55 said:

https://www.sdxcentral.com/cloud/containers/definitions/containers-vs-vms/

It basically removes the overhead caused by running a full vm for each scenario.

If you need 5 vm's for each a specific function, you need for example 5 Server 2016 machines, and instead of running 5 you only run 1 while keeping all the services apart so you can add and remove them if you like.

So am I getting this right? A container is a single os but can run multiples of the same programme? 

[jde3]

I know a lot of people do this.. usually for security but running a container in a VM is also kinda pointless. Your loosing the benefit of the container.

[Njordic]

Just now, jde3 said:

I know a lot of people do this.. usually for security but running a container in a VM is also kinda pointless. Your loosing the benefit of the container.

Awesome, thank you guys

[lacion]

Just now, jde3 said:

A container is virtual server that shares the hosts cpu, ram and disk storage. It's similar to a VM but it does not run a different OS.

 

They work a little differently depending on what your using but in FreeBSD's case a jail would give you a root and look an smell like it's own computer but it would share the resources of the host system instead of you provisioning set resources. (tho that can be done too)

 

Docker is a type of container, namespace and cgroups.

that's only slightly right, By OS you mean different kernel in docker you can have a debian/ubuntu host but you can perfectly run a fedora or centos container with no problems. 

 

containers are not really like VM's at all resource wise, while a VM means you need to run full features OS meaning CPU and memory for all system related processes, in a container you share all the base system resources with the host.

[lacion]

2 minutes ago, jde3 said:

I know a lot of people do this.. usually for security but running a container in a VM is also kinda pointless. Your loosing the benefit of the container.

well.. not really this is exactly what the cloud is, plenty of people run containers in the cloud. containers are not VM replacements, they are a packaging method. 

 

think of them as a binary file that runs an app, inside the container you will everything you need to run an application, its dependencies config etc. meaning you don't have to install all of the stuff the app needs to run locally on your computer as its all package inside the container.

 

while you can run different distros inside a container, you cant run different kernels. hence why running a Unix container on a Linux host will usually result in a bunch of weird errors.

[jde3]

FreeBSD dosen't need to run a container in a VM.There is also Solaris/Illumos and Zones that do not as well. (I know docker dosen't but most people do, just because thats true dosen't mean it's right it means linux's implementation is broken.)

 

And debian ubuntu and fedora are all the same OS.. just different tweaks.

[lacion]

5 minutes ago, jde3 said:

FreeBSD dosen't need to run a container in a VM.There is also Solaris/Illumos and Zones that do not as well. (I know docker dosen't but most people do, just because thats true dosen't mean it's right it means linux's implementation is broken.)

 

And debian ubuntu and fedora are all the same OS.. just different tweaks.

the only OS's that need to run containers in VM's are the ones that have no native support for what docker needs (OSX, and Windows.... at least for a bit native docker windows support is happening right now)

 

the OP did not specify what different OS's he wanted to run things on. plenty of people refer to different distro flavours as OS's, I'm just not assuming anything here.

 

Note when i say container i am mostly referring to docker, i really don't have a lot of experience with any of the new players, and its been a long time since i LXC/LXD to talk about the state of that now days.

[jde3]

If your into tech talks.. this is entertaining.

 

[lacion]

8 minutes ago, jde3 said:

If your into tech talks.. this is entertaining.

 

i actually seem that, looks like a rant from a sysadmin having a hard time adapting to new times.

 

that's the usual confusion we get nowadays with the new methods for deploying software, VM's are not going away, docker is not replacing VM's serverless is 99% of the time backed by containers.

 

what we call serverless is just an abstraction for end users, for them there is no need to worry about the server its just their function running and that's it, same happens with containers, they create it locally and it will run the same no matter where they don't have to worry about the VM.

 

that's what modern SRE and DevOps do, create tools and workflow where all the systems complexity get abstracted into a nice easy to use and understand layer, with a ton of shit on the background doing all the heavy lifting.

[jde3]

11 minutes ago, lacion said:

i actually seem that, looks like a rant from a sysadmin having a hard time adapting to new times.

 

that's the usual confusion we get nowadays with the new methods for deploying software, VM's are not going away, docker is not replacing VM's serverless is 99% of the time backed by containers.

 

what we call serverless is just an abstraction for end users, for them there is no need to worry about the server its just their function running and that's it, same happens with containers, they create it locally and it will run the same no matter where they don't have to worry about the VM.

 

that's what modern SRE and DevOps do, create tools and workflow where all the systems complexity get abstracted into a nice easy to use and understand layer, with a ton of shit on the background doing all the heavy lifting.

I don't really understand your point here. Are you trying to say, improvements are not important?

 

There is a right way and a wrong way to do something and tossing it up to "backend abstracted magic" is dangerous because... you ever heard the term garbage in garbage out or do they no longer teach that in computing?

[lacion]

1 minute ago, jde3 said:

I don't really understand your point here. Are you trying to say, improvements are not important?

 

There is a right way and a wrong way to do something and tossing it up to "backend abstracted magic" is dangerous because... you ever heard the term garbage in garbage out or do they no longer teach that in computing?

not saying that at all.

 

Abstraction is very important in big distributed teams we see nowadays, and it's very important in order to move fast at scale.

 

i cant spec every developer to know the systems as well as they know what they do. so DevOps/SRE abstract things to make it easier and avoid them doing stupid things that will bring down production systems. 

 

it's impossible to Spec Ops/IT/DevOps/SRE to be the gatekeeper of productions when there are hundreds of deployments and thousands of things running in prod.

 

so things get automated and some other things get abstracted making service ownership a thing, giving the team who created something full-service ownership from development to production makes them more agile.

 

things like kubernetes, terraforms (your flavour of configuration management, puppet, chef, salt, ansible) they abstract things a lot making it easier allowing people to do things that in the past required Ops team or IT to do. additional layers of abstraction can be added by setting rules to avoid people going to crazy and keeping the same system. 

 

thanks to all the abstraction we now get with VM's, Containers and API's we can have teams more focused and delivering faster.

[jde3]

Your talking to a Sr. System Administrator btw. You know that devops (I hate that term, its a marketing term, operators are operators and devs are devs, they think differently.. so lets just say Ops because this has to do with them ya?) Ops are real people not robots or scripts who have actual serious challenges? Compute isn't infinite because money isn't infinite. You can't just rent your way out of every problem when you've bloated the software stack to all hell because you won't look at what the abstractions ACTUALLY are. Efficiency matters.

 

I stand by the statement. Containers running in VM's is dumb. Hea world, fix docker and Linux so we can stop doing that.

[leadeater]

49 minutes ago, jde3 said:

I stand by the statement. Containers running in VM's is dumb. Hea world, fix docker and Linux so we can stop doing that.

There is room for both methods and there are a lot of factors to why a certain approach is picked or viewed as better. There are reasons to run containers in VMs and when you encounter them it makes sense.

 

Docker covers one reason here, https://blog.docker.com/2016/04/containers-and-vms-together/. Then there are more background reasons like vMotion/Live Migration of a container host to different hardware without interruption or deployment workflows, it just works and you can get on with doing hardware maintenance immediately without having to consult with every container owner. While it's possible to do container level migration it's not to the same refined level as VM migrations are, and relying on container restart policies is not a good idea in the absence of live migration capability.

 

There are a lot of things VMs do better than containers currently, as to be expect from a more mature technology, so combining both is a win win when it makes sense to do so.

[lacion]

1 hour ago, jde3 said:

Your talking to a Sr. System Administrator btw. You know that devops (I hate that term, its a marketing term, operators are operators and devs are devs, they think differently.. so lets just say Ops because this has to do with them ya?) Ops are real people not robots or scripts who have actual serious challenges? Compute isn't infinite because money isn't infinite. You can't just rent your way out of every problem when you've bloated the software stack to all hell because you won't look at what the abstractions ACTUALLY are. Efficiency matters.

 

I stand by the statement. Containers running in VM's is dumb. Hea world, fix docker and Linux so we can stop doing that.

I'm a Sr. SRE, DevOps is not a marketing term is just something that's been miss-used by a lot of people. DevOps Teams are composed of a different people from different background all working towards the same goal. 

 

you are totally entitled to your opinion, I was just discussing with you,  but I totally disagree with you, most of the stuff "WE" do (ops, sys admin, it, devs) can be automated and abstracted away giving you more freedom to do what really matters, more focus and stop worrying about meaningless repetitive tasks.the new terms and titles "DevOps", "SRE" and all the variants are not replacing anyone, their just specialized positions, Generic "DevOps" teams still have Sys Admin, Devs and IT in them all collaborating with the new specialized persons to create even better systems and infrastructure.

 

 

there is a very good reason everyone and their mothers are using Kubernetes nowadays. but i can tell you, deploying a kubernetes production worthy cluster on Cloud or Baremetal is not for the faint of heart, and it requires deep IT and Sys Admin knowledge to do right.

 

4 minutes ago, leadeater said:

There is room for both methods and there are a lot of factors to why a certain approach is picked or viewed as better. There are reasons to run containers in VMs and when you encounter them it makes sense.

 

Docker covers one reason here, https://blog.docker.com/2016/04/containers-and-vms-together/. Then there are more background reasons like vMotion/Live Migration of a container host to different hardware without interruption or deployment workflows, it just works and you can get on with doing hardware maintenance immediately without having to consult with every container owner. While it's possible to do container level migration it's not to the same refined level as VM migrations are, and relying on container restart policies is not a good idea in the absence of live migration capability.

 

There are a lot of things VMs do better than containers currently, as to be expect from a more mature technology, so combining both is a win win when it makes sense to do so.

 

not to mention all the development benefits, including running the same thing in dev that you run in prod with absolutely no difference. 

[leadeater]

6 minutes ago, lacion said:

and it requires deep IT and Sys Admin knowledge to do right

I'll just bold this part because, well.... anyone can do it wrong 

[jde3]

1 hour ago, lacion said:

I'm a Sr. SRE, DevOps is not a marketing term is just something that's been miss-used by a lot of people. DevOps Teams are composed of a different people from different background all working towards the same goal. 

 

you are totally entitled to your opinion, I was just discussing with you,  but I totally disagree with you, most of the stuff "WE" do (ops, sys admin, it, devs) can be automated and abstracted away giving you more freedom to do what really matters, more focus and stop worrying about meaningless repetitive tasks.the new terms and titles "DevOps", "SRE" and all the variants are not replacing anyone, their just specialized positions, Generic "DevOps" teams still have Sys Admin, Devs and IT in them all collaborating with the new specialized persons to create even better systems and infrastructure.

 

 

there is a very good reason everyone and their mothers are using Kubernetes nowadays. but i can tell you, deploying a kubernetes production worthy cluster on Cloud or Baremetal is not for the faint of heart, and it requires deep IT and Sys Admin knowledge to do right.

 

not to mention all the development benefits, including running the same thing in dev that you run in prod with absolutely no difference. 

This isn't new stuff. Before kubernetes was cfengine. Remember MySpace? They had this problem, they would put untested development code into production all the time and they would look on the site to see if anyone had a problem.. what would happen to them is if people couldn't get to the site they would have NO IDEA it wasn't running correctly. But its all good because they were "agile" right?