Yeah, so hello nice to see all of you Yeah, my name is Fabian Deutsch, and I'm going to speak about cupid which is about running virtual machines on containers I

Worked on overt which is a virtualization solution for a couple of years, and then we went over to work on cupid What people from over then open stack are working on and I'm working at redhead Linux company doing Linux stuff, so If we start then we can say that virtualization is only present today

Oh the focus of this talk is obviously or it was in the light of this track to say persistent migration, so how do we how do we get from today to to something in the future and Virtualization is only present today that means it's everywhere good morning

So it's getting crowded I think this So virtualization is omnipresent today that means you you have virtual machines everywhere You've got them classically in the data center where you got your own virtual machines to run your Oracle database Or you got them the cloud and GCE and Amazon in Asia where you can create

gazillions of instances with the snip of a finger But In this case it's really about about you or about us. How do we get our virtual machines over to? To the present day, and it's not I mean today. We just don't have virtual machines anymore, but we also have

containers they came up in the recent years, and I guess that You all know containers so who of you has used containers before Nice and who of you has used virtual machines before oh, that's perfect there you go, so

Containers are here as well the question is If we look at them and And we look at them and we see them and we see all the heights And we see how much is done with containers that's so fancy tools with so fancy names and and they look and taste and smell a little bit like like virtual machines and

But just better because it's new and it's hyped. It can do everything you won't have any bugs and and then you Do get to the point where you where you ask yourself? How can I replace my worms with containers there are several reasons for that I mean

Efficiency is one obvious point you can say that more containers fit on a host than VMS do they're quicker to launch and eventually Easier to manage because they are text-driven you have a docker file You can write in there whatever you want And you just rebuild the image if you want a new version, so that's really handy in VMS

You need bigger provisioning tools you use Ansible assault or templates and open stack so Containers are and we need to grant that are really easy to handle and so at some point you might of who has asked himself If you can replace your VM with a container okay at least a few

Why didn't you ask yourself why you want to replace them ah you want to suffer Yeah starting from scratch like a new car you don't want to take your old car and give it your pain

Yeah, so I think we're good on time so we can make a little next course so The thing is if we speak about replacement Then we need to ask ourselves. Can they really substitute each other so can containers actually replace VMS and

As said you look at them, and they look the same you can do some of the stuff Oh the management tools around them are also pretty similar, so you've got Kubernetes and there's Docker swarm and I I Read one of these new tools from SUSE what it was a cold I don't know lighthouse or something like that So there are a range of tools which which help you managing containers and also around the whole life cycle

So there's really a lot of stuff around containers But then if you look in the detail What technology is used what impacts does it have? For your application I mean in the end we don't run VMS for fun or containers for fun We run them because we want to deliver an application to users, so we run a VM with a database

To give an admin the database needs or we run a VM to give a user a desktop on demand so there's a reason why we do it and So what why I'm saying that is because We run them and we need to see if they yeah if we can replace them so

We need to take a look at the technology and see to see if If containers can give us the same as VMS so for example if we speak about desktop Which in a university for example an admin is providing to users on demand like for I don't know for doing a course or class of programming

task or so They might use a more desk remote desktop solution, and that's just not available in containers So they can do obviously a serial console, so but it's things you need to be aware of Or if you got in it in a hospital, they'd use remote desktop solutions to to have their

Specific application for handing out on a scans or so remotely sometimes and use smart cards for authentication So in these classical virtualization world you've got the features to do Path through of the smart card from your thin terminal to the server, but it's not there yet in the container world

But on the other hand Containers provide different features containers are easy to scale so if we look at Kubernetes You've got the possibility to take one container and scale it up to hundreds Which is not so easy with with VMS on the other side so there are technical differences Even if they look and feel the same and if they really fit into your use case

That really depends on the application you are supporting for your users, so if you can replace a VM with a container really depends it depends on the use case you have Okay, so in case you can replace a container with your VM your VM with a container you're all good, so

It might be a Java application. We can put into container, and it's really simple. You don't have to do anything Well a year later You're you know that you have to do some stuff to really make it efficient and fit your application to container So it's not easy But I want to focus more on the case where you can say no

I cannot replace my VM with a container because of certain constraints I mean today the virtualization world is there for I don't know 20 years or so In different stages and the applications we have evolved and they grew in that system, so you have big monoliths Lifts which are optimized to run in the VM they make assumptions about the operating system about how you deploy stuff

So everything we as admins or we as developers did in the last years was Was built on these assumptions we have referred from machines like a lot of tools have have UIs So there is the expectation that you have a screen to display that UI, and you don't have you don't meet that

Requirement in the container world where you just have well you can say it takes UIs UIs well I'm speaking about really GUI applications and Surely you can take your application and change it to to meet the container Technology, but it takes time to change an application if we think about complex applications

I don't know for big business processes. You need to change them you need to adopt them and So you might say I cannot replace my VM right now with a container, but I want to do that in the future When my application is ready for that Good so now regardless if you want to start now

Or if you want to start a future at least we're here because we say We see the transition is happening We see we are in the VM world today, and we want to get started with containers in production really I mean seriously we want to get started so the question is do we start from scratch with shiny new things and everything works

I think if you look at the containers themselves it absolutely makes sense I mean you want to build up your container infrastructure from stretch and look at it, but if you look at the application are you using? virtual machines production Okay, so would you say the application you provide to your customers or to your users?

You would start that application from scratch, so you would rewrite it to fit into the container world no Yeah, that's quite a lot of work So I think the infrastructure will be started from scratch to host containers But the application yourself that is not something you want to rewrite so we need to see how can we I mean we do we provide our application customers because we make money and

hopefully and We don't want to rewrite that just for the reason of moving to a new new infrastructure, so In reality we need to find a way how we can gracefully move over We are here that is a fact and we need to provide and continue to provide our product to customers or to users and

The question is how can we still do that? How can we keep providing that application to users even if we move our infrastructure for example in the direction of containers because of the benefits? They have and they support different development models

I mean agile is a big word in that world and DevOps and oh there are so many cool words Their words yeah, so it's not it's not that we want to write our application from scratch But we rather want to see that we support an evolution so that we take our Application and gracefully move it into the direction to be able to run containers, so we want to evolve it

So how can we do that and that is that is slowly the point where I want to get at with this presentation Is how can we support the transition from the classic data center and cloud world today with the classic? application with the legacy You can call it legacy applications. We have today and

Into that new world we have decomposed Applications microservices running on service meshes, and you can find another or more buzzwords here as well so the classical stack Very simplistic is that you have your infrastructure your bare metal infrastructure, so you've got your storage

San or nose Dedicated you've got your network switches And you've got obviously you've got your physical hosts, and they are aggregated into some kind of management plane, so you've got your virtual machine management application VMware overt open stack There are many others just in a few

and And on top of them you've got your virtual machines running which you need to keep running, and I'm continuing to highlight that because We I mean I'm quite paid by redhead and we live in the reality that we need to see how we can really support our Customers and that is really what is driving us. How can we get them from today into the future?

We need to give them enablement, and if we want to support them in that so that is where we are today and Then we say okay, let's start from scratch and bring up our new management plane Which is optimized for containers, so we need storage again. We need network again. We need service again and Then we'll have a management plane dedicated to containers yet, and do you see that on the right side with the blue box?

But that means you have twice the infrastructure Depending on what your setup is you need to dedicate Your storage device to this container use case and you need to dedicate a network and overlay network whatever to that container use case So you I mean if you want to start if you want to POC something if you want to get feeling for it

That's totally fine, but we speak about really the serious migration after that you see containers work for me and somehow I need some time to migrate my stuff, but that works then in that case you probably don't want to maintain to production great

infrastructure parts in your company Actually before we you actually want to Maintain a single one you want to back up a single fan or nuts and you want to make sure that the single Instant of switches are running and that you don't have to Double everything actually there's another set up what you could do you could say I take my existing virtual machine setup and

On top of that I built my container management plane So everything above the orange box is then virtualized, but the problem here is that You still have two infrastructure layers because you've got the real one at the bottom and the middle one where you need to provide

virtual storage so you need to have a VM which is serving storage and Networking is not so problematic, but you still need to manage it in the virtual machines So you still have an overhead because you have got two different layers where you need to provide Infrastructure either for virtual machines or for containers, so it's not I think it's good for the POC case

And people do that very often who did that who use virtual machines to play with containers Oh, yeah, very good. That's good for the statistics, so Yeah, that's very convenient, and I agree, but again in practice. It's then You still have to maintain two two infrastructures So and that's why we get to Qbert so Qbert tries to exactly

Go into that area so Qbert provides you the ability to run contains the virtual machines on the same infrastructure so you don't have to provide two different two distinct set of of Components for storage network and

Just physical hosts all the stuff you need Eventually to do two data centers or two rooms physically it depends really on what you want to provide to your customers So how does it look? simple so Qbert allows you to use the same management plane and to use the same Physical storage and network virtual storage and network and other components you have in your in your in your setup

And The management plane in this case is is kubernetes But why is it better or why is it good in our opinion is because it allows you I mean The orange box is so large because we have the assumption that today you have many virtual machines And you start to play with containers

But over time you want to move stuff over where it makes sense So we said some applications can be faster than others depending on their requirements some Might not be able to to be moved Ever if we'll think about security aspects if somebody in the room is working with security you might know that you need VMS to have

Real complete or worse isolation. I don't want to go into the container details, but Containers have these yeah They effectively shared the kernel as you all know And VMS provide the ability to to not share the kernel, but have your own kernel per VM Which is good if you want to do, I don't know some testing on that kernel Oh for oh yeah testing is a good example if you want different architectures

Then you on a single host then you still want to have VMS because containers is not It's not the component which can give you that so yeah so you can slowly move in this light you've moved more more stuff from the virtual machine side to the container side and

The good thing is the storage network. It's not twice there in the picture in reality that really Helps admins to keep the oversight over their components Yeah, and in the end Doesn't look much different I said you might want to keep some VMS where it doesn't make sense to to move to containers

Whenever you've got questions interrupt me, I think we've got enough time Regardless Now that we've looked at these overview Why what we want to have qubert because we look at it from the reality standpoint you cannot build everything from scratch again

Because it's all money. It's all time you need to invest so we wanted to see how we can provide a migration path for your application so Let's take a look a little bit A close look at how how this looks technically so this was pretty high level so far And I want to get a little bit more into detail

So kubernetes is the management thing we built upon which is classically the And a framework to run containers on a common cluster on a number of hosts But it doesn't provide the ability to run virtual machines. There are different projects

I mean we have qubert qubert is the very best here by far now But we've got other projects like wordlet and rancher and they try Something similar, so they also run virtual machines and kubernetes, but with a different focus I'll get to that in a minute so In very simple pictures if you now add qubert to the picture, then you are able to run virtual machines

and All right, so and that's actually a slide missing. I should have ended that so Why is qubert different than for example wordlet or rancher? Oh who has heard of wordlet or rancher or clear containers?

Rancher great ah really really interesting to see I think rancher is the project which isn't Closest to to qubert by the way and the difference to rancher because it seems to be common sense here and is

No, not not a difference to rancher but in general our take is that we want to express the M's as they are so if you look at the M's and containers or if you look into one of the kubernetes introductions Then if you look at the difference between VMs and pods you see that they have different properties And we spoke about that so you can VMs can have architectures

But don't have that it's implicitly dictated by the architecture you have below the M's have kind of multiple displays Pots don't have that graphical display at all is not something what what pots have? Multiple networks physical different devices if you want to test device drivers or do device pass-through

That is it not something can simulate in the pod you can for sure provide a network interface to to a pod but It's not device. It's a network device, but it's not not it's not driven by a real driver It's not you know you do

That's now. I've got into those details which are difficult to explain So I don't really have device drivers for that for example if we look at the vth is in the kernel They are not physical devices. They are concepts inside the kernel to to connect containers to to the host namespace and Why I'm saying that because we think that there are enough differences between pots and virtual machines

that Vms need their own definition So if no one's taking and please correct me it has been some time at least wordlet Is one of the approaches which is running vms with kubernetes, but they implicitly derive the VM from the pot specification

So there for example, it's they have some workarounds they use annotations to number to specify the number of CPUs But if you want to reuse a specific disk or they use the volumes of pots to to attach disks but setting displays adding USB devices, that's not possible because they derive it from the pot spec and

Clear containers is doing the same so they look at the pot and derive a VM from the from the pot spec But I said the pot spec does not provide enough details to To to to define any VM you can have if we look at that and operating systems from Microsoft like Windows

Then it's a fact that you need to have a stable hardware AVI over time So your devices should not change. Otherwise, you're asked to read register or reauthenticate I don't actually know the name of the process But you need to call Microsoft to get your own activate to activate your windows again if the hardware devices change

So we would really like to keep these VM API or AVI stable over time with the rancher or virtually Yeah, even for answer with the rancher wordlet and click dance approach It's not possible if you do updates and kuma changes below The AVI will change depending how often that happens. You need to activate it at some point. So we said

We want to expose the VM AVI so the virtual hardware Completely as an entity in kubernetes and that's that's an important that is the difference between kubernetes and other solutions So if you look at the VM AVI in kubernetes, then you will see we can actually do that

That you can express Really the VM details and that is necessary to keep that VM AVI stable over time who's familiar with Libbert eventually That's good, so Libbert is that such a component which has been around in the virtualization area of Linux for a long time and

We use it internally and that is why the VM definition looks a little bit similar to the DOM XML if you have looked at a different and

Here also see and that's actually the first bullet On that slide is of the second bullet that we have a new resource type for VMS That is what you just saw so we've a specific dedicated VM type where you can specify many details So it will take some time to recover all the details because there are problems in the details

or if you think about performance a very good example and VMS often tuned for performance and Then you get to funny things like Numa where you need to make sure that certain Virtual processes are tied to the right physical processors and if you do device path through that the device is really aligned with the device node of the virtual CPU and

That is stuff Kubernetes does not care about yet They are working on it, but we need the tight control over it because we speak about series VMS We really want to provide production ready VMS, which you can use and support over over time and So what we can do is we can use this extensive VM API. I just you

I've just shown to to to pin CPUs to certain physical CPUs Right so I spoke about the API One thing is that we want and I'll go to the first bullet is that we provide everything in parts

And why do we do that if you look at virtual adventure I clear containers take all three of them Currently you cannot run it on any Kubernetes cluster because it makes assumptions about the hosts below so You need to install Invert in the verlet case it assumes that kumo is around it assumes that

The relevant kernel modules are around so that is stuff which If we look at Kubernetes, it's all about the cluster you usually don't care about what operating system is below Kubernetes Because you can run Kubernetes on Debian Linux On Debian Linux on Fedora and Susie core OS whatever and you usually don't care

What is below you I want to I have my container? I want to run it on the on the cluster so the new platform is the cluster and not the host anymore Which is good But in this existing solutions what we identified as problems They do rely on the underlying host and that limits where you can run the solution So we try to provide all the dependencies and pods so that you can deploy

Kubert like any application in Kubernetes you don't have to roll out anything else Actually we we try to be that good that we can act as a Kubernetes at on so that you've got namespace awareness And that you integrate with with the networking concepts that you recognize the network policies and all that kind of stuff

We try to be a good citizen as well by being by being based on an operator pattern That's in a pattern introduced by chorus. I just The important part the important part here is that we try to behave so even if we are virtualization and virtualization conflicts with containers in

certain fields But we still try to behave nicely on the cluster So we also want to be decorative like you can declare pods or the state of pods and we want and we Follow this pattern by implementing the operator pattern So the last bullet point here is the M's live inside pods

It's on the one side an implementation detail, but often it does people do care about it. So that's why I named it so The M's are not pods in in our implementation, but the M's live in the resource group of a pod What's the difference and why does it matter anyway, so?

We have the ability to say that we run and it might come at some point, but doesn't it's not so important yet, so if we run pods Cooper the only unit Kubernetes aware of in the case of Of a specific look workload is a pod all other concepts are built on pods. So our high-level concepts to pods and

What we said is alright, so kubernetes tracks pods, so we want to see Especially tracks resource usage and it applies limits to pots. So what we needed to make sure is that we really That On the one hand kubernetes is able to track VMS the same way so that is why we place them in pots

But you could still say well, but why don't you for example? implement VMS in kubernetes And that is where we we get to to these conflicts again if we implemented VMS really inside Kubernetes then we have the problem that

certain functionality Is just not there in kubernetes because it doesn't fit with those concepts for example if we think about life migration who used VM life migration in practice a Few people it's very convenient because you don't have to bring down and call your customers say yeah It will be back in 20 minutes, but you migrate your VM and it often works

We had a lot of time to optimize that process But it's not there in the container world for you can implement that I Wonder how good it will become But it's conceptually not something you have with containers containers are stateless you how was it called yesterday?

They're mortal so they can go away And you just re instantiate a new one and that is not something you want to do with production VMS of legacy Applications you want to keep them around that's what we live migrate them So we want to have life migration But we knew that we cannot bring it into kubernetes because it clashes with the concept of containers

So that is why we say that whole VM logic is a top kubernetes It's a layer of top kubernetes, and it's leveraging the concept of kubernetes And that's why we use pots we see a pot as a harbor for a VM So you bring a pot and that and that's where we place the VM and if we do a migration We just create a new pod then we move the VM from one pot to the other and kubernetes can kill it afterwards

So the state of the VM is not tied to a pot which is good because that is how kubernetes handles pots and containers But we can still deliver our functionality of doing the live migration because we just see them as as Resource constraints or good resource containers for VMS if I'm getting too technical or too detailed

Please let me know or if you've got questions. Also. Let me know All right, so we look at the VM API. That's good and Because we're getting Already to the end. I think we'll schedule for 45 minutes. We can get our hands on I hope it works. I'm confident it does

so Has anybody tried minikube before All that's cool for all the people who didn't lift the hand I would really recommend it minikube is so nice to try if you want to get your hands off with kubernetes Give minikube a try. It's really it's like I'll just Google minikube or Bing minikube or

DuckDuckGo minikube you will find it So the demo I'm going to show maybe we can still switch again. It's based on minikube I'm using the VM driver KVM. Which is just important because It's fedora and it's Linux and you can have different drivers important is to use the network plug-in CNI

It can actually clone that demo, and I hope it works for you as well The slide will be public later on in case you really want to give to try and so What I'm doing now is

That we will be quite small put what so what the demo does it it clones cupid from github So we are all public. It's nothing secret even if we do it as a company for Or so it's all public with all the issues there You're welcome to contribute welcome to try welcome to file issues welcome to fix them So what happened is we cloned that repository and used the manifest so we provide all kind of manifest so here we see

We've got a vert controller, and we've got a VM resource So the VM resources is our own VM definition the API we saw before the controller is related to the operator pattern So it's watching for new VM definitions, and then acting upon them

We've got the handler Which is a demon set and we're deciding on every note and making sure that if a VM is getting scheduled to a specific host That we that would really launch a VM if it's getting scheduled to a specific host And all these components were now Deployed on me cube if you do it for the first time it can take depending on your internet connection sometime because images are

Pulled down, and it's still early phase, so the images are quite large it will get better over time So We look what kind of puts are running now, oh, that's too large Yeah, that's better We see that we've got a few components running so we've got HA proxy

If anybody wants why HA proxy then lift your hand, but we can ignore it we've got a nice cut the demo target because we I'll get to that in a minute We've got liver spice proxy to give the graphic console excels from outside the cluster word API

The controller I explained that the launcher test VM is actually that is the part which I said which is launched to provide the resource container for the VM and We've got the word manifest Yeah, which we want to get rid of or maybe not let's see So these are really components, and it's a stock mini cube

deployment so what can we do now we Looked at the bots and what we can do. Oh, yeah, we can take a look at the liver container for example to Just confirm that we really have a VM running, and that's really nice if it works, so

You see so what I did is so we've got the word the word launcher test VM And that was scheduled on a specific host where this part for opening the resource group for that VM was launched the handler saw it and

Told liver to spawn a VM based on the VM API which is also declared actually let's take a look at the VM API Oh, yeah, oh, that's nice Because we've got our own Type in kubernetes we can actually use the whole kubectl

Tools to retrieve these commands and actually the goal of kubernetes We want to be friendly citizens, and we want to work with kuber Kubernetes, so You know today kubectl is pretty much tuned to what the Kubernetes case So it has all the verbs to work with containers, but it doesn't support live migration for example

So we want to work with the communities guys We actually providing our input there to make sure that for example in this kubectl case we can add our own verbs And if you're tracking the communities progress, and you might have seen that kubernetes or kubectl now I think one seven or one eight is supporting binary plugins on the hosts So you we now have the ability to provide our add-on to kubectl to then provide verbs which are relevant

Virtualization so we can have our verb k kubectl live migrate and the VM name for example

So in here see That is really the VM definition as it was shown on the slides and that is used to bring up the VM on the host and if you look above it has all you know it has the feeling of

Kubernetes even if you can express the all the VM requirements you can work with labels you can work with tanks and tolerations So you can really leverage the infrastructure a word on the infrastructure So we started with that on the first slide we said Containers and virtual machines if you want to run them today in production you need separate infrastructure basements for both

In kubernetes, it's not really used in this demo. I actually should update that If we look here we see that So this little this little section says That we add a disk to the VM But it's not using a persistent volume from kubernetes in this case, but rather directly nice car the device or a nice cozy target

But what we work on and it's actually merged So I should update is that you can use regular persistent volumes of kubernetes instead of four for pots You can use them for VMS. There are certain constraint constraints So virtual machines don't support file systems at disks you need a raw block device or or a device which is

providing raw block device like semantics and So we work with kubernetes we actually Now have in kubernetes 1.8 the first raw block device support, and we try to engage them you know we try to really get it into kubernetes on the long run that we have stable support over time and

You can use PV's with with the VM spec so instead of Referencing an iSCSI device you can use a PV like you could use it for pots So and the semantics about exclusive or the access modes multiple reader multiple writer are are recognized

What we are currently working on because that the second part large infrastructure part is networking And that's actually more tricky than storage And we also working here or collaborating with with different parts to see that we get networking for VMS Aligned with the infrastructure of kubernetes What does it mean we just want to connect in a simple way? VMS to the same networks as kubernetes is using it's more complicated than it sounds at the beginning

All right, so the demo is running We showed the VMS. We showed that it was running If you follow the complete demo, then you can download the binary tool, and then you can do stuff like Mm-hmm

What's a keyboard demo Cluster cube CTL And then you can do stuff like console test VM the issue is that we lately move to a new binary tool Which is a pre stage to having that at on for cube CTL

Which I did not install yet, and we can then directly access the console you can even say cube CTL spice spice test VM to then open a Spice window yeah all right, then we can move back to the slides

And that's quick But yes, it was the last part the demo is often good to put at the end because you never know if it works, so Yeah, that's it from my side. Thank you very much so far other questions Very good

Attention Yeah So the question was what is the problem with networking and the problem of networking is conceptual so so many problems with Kubernetes and VMs are conceptual so

What you get in a pot is not in you get an interface But that's just implicitly what a pot is getting and the core concept is that every pot has an IP So Kubernetes is dictating that the pot is getting an IP, but in the virtualization world you don't give An IP to the VM I mean you will might do it if you have a DHCP server on your LAN

but you effectively give it an interface so layer 2 connectivity and So we need to say how we can so we've got Actually a colleague of mine is implementing now layer 3 connectivity for VM so that we can really play nice with stock Kubernetes networking But the core problem is we need to address is we want to give VMs the ability like in our classical data center today

To choose their own IP and just provide them the layer 2 networking where they live on Yeah, you could say we could actually say we don't want to do that We just want to keep it the Kubernetes way and manage the a piece for them so to do IP address management But we know that it takes time to legacy application support of living with the fact that they now get an IP

And that they cannot dictate it anymore So but our first step is playing nice And we're close to get there and that will work with CNI So we will we are requesting new interfaces for us from CNI for each NIC for each virtual NIC we assign to a VM

That's currently a work in progress, and I'm happy to show it next year or a coupon. That's it Any more questions to that or okay? the man in blue

Like the emperor and liver So

The question was why do we invest anyway if the VMS are going to die? That's a good question. We should probably stop now Yeah, I think the assumption is that VMS don't die so quickly and we just even if it's quite some effort after all it's not so much It's actually pretty nice. It's a technical challenge. That really is fun working on that. Thank you. We've got five minutes left

But we need it. I think it's worth the effort because It really takes time and sometimes it takes more it We all know it often takes more time than you estimated at the beginning So we know it will take time and if we look at how many you know a lot of companies still get money

from moving stuff from Unix to Linux and Unix It's pretty old so we know that transitions take take time And we want to provide the solution for this transition path But we don't want to have you being stuck with the infrastructure I think companies will will eventually stop supporting all the infrastructure

I don't know if VMware now really goes up in just supporting containers What do you do with these words these very V sphere is not seeing any updates anymore That's what we say you still need to run your VMS But you also need to be up today to have security updates and that kind of stuff So we say it's worth the effort to say we allow you to move the VMS to the new infrastructure, but keep your classic VMS running until you are ready and

Eventually and there are reasons often again where where you see that VMS are needed like For relief if you want to do testing on certain architectures CI is such a big thing and it does it works for on the application level for with containers

But on the lower levels just doesn't and this that is what we know that VMS will stick around Also for certain isolation techniques. We know that the isolation of containers because of the single kernel approach Some say it's not as good some say it's sufficient, but regardless of that discussion

There are regulations which require to have a strong virtual machine isolation Eventually these regulations will see an update as well But so far they haven't and in these cases to meet regulations of governmental regulations. You need to run VMS So and and the question is open if really VMS will die or not to me

Oh

Flat back this container run time Yeah, so does what was the question? and can't Flat back is it who knows flat back? Oh? If you've got too much time take a look in flat back We really need to give it some power and give it some love so flat back is

It's a user-friendly offer users of container format, no not a container format. It's a container runtime Targeted for unprivileged users, so you don't need root access to run containers And the question was why can't we reduce classical containers to run applications? Why should we use flat back and I think it's after all it's the same

Technically they also you see groups. They also use namespaces. They use user namespaces That's why they can run unprivileged which is important characteristic But image wise they are very similar they might use different techniques on the low level But the core concept it's a container they ship dependencies in a container so to me

It's not so much difference, or was there something I missed in the question I Okay, so the question was and I did it got it wrong. Sorry

The question is why can't we use flat pack to run desktop applications? It's difficult to run flat back windows applications in flat back if wine doesn't support it And it's difficult to run a power PC or power 8 power 9 application in flat back if you've got an x68 64 host

And that is where where VMS again come into the game, so we said that initially in the talk Why what are the differences between VMS containers? And it's like they are so it really depends on the application if it's like t-marks I would say all right. You don't need a VM for t-marks. You can use a flat back if you run calc Or a color the calendar application on the terminal you can use flat back

But if you use oh even if you use gnome if you know just gnome calculator, you can you can use flat back it's you know it's You can get it for the arc Architecture you want and it's Linux based. That's not a problem, but if you really get to the details you want to have any have a

graphical application which requires oh well Let me it depends on the requirements of your application If you need remote support what kind of strong isolation you need If you need a different kernel because of different architecture or different features those those Those questions playing to the decision actually we had a diagram early on

Well, it said it depends you can port some applications directly come to containers But often legacy applications which have grown over years you cannot directly move them containers You need a transitioning period to adopt the applications I Hope I got it better now anything else

Who of you will now try cupid? That's good any more hands. I would like to see more. That's no very good If you've got any questions get us on IRC. Oh, I missed to put I see their Twitter get up filers contact us We all friendly well humans, so

Happy to see you there, and thank you very much for your time and good morning