OpenBSD: add VMM to 'packer' (porting Go software)
Buehler, Philipp
The sysadmin view of virtualization usually starts at a hypervisor running some kind of "image". Packer is a framework to create such an image using various host and virtualized operating systems and adding some more bolts. This talk shows the efforts and pitfalls of building a plugin for packer using the VMM framework on OpenBSD. Some details go down the rabbit hole (or reducing it) to provide a Go binary runnable as a plugin. For ease of installation, the ways how to package this as an OpenBSD 'port' are shown. On top a bigger picture is provided on how to provide configurable OpenBSD images "at scale" by using the above accomplishments.
 Okay, welcome to my talk. I'm Philip. I'm a gimmick snore for about 225 or something years now for three or four years that was obviously developed by the media. asking them what we are and what we are. So this is still what's going to be said about. So the main thing with all the virtualizers is how to get a good little system image, you know, network or very weak means like for example, Amazon streaming, drop-wise, and that system that I can't get to go. So the least common denominator for our HSS watches files, we have a code that has to pick up the food sector and bring the whole stuff up. So my tactics especially is I want that infrastructure to grow as I named it, which means all the stuff we are doing physically in the data center or whatever, I want to have my laptop itself to simulate all the outprovisioning process. And that should even be working for sitting in a plane or in a data center with a good parabenic H style of protection. And that helps me to have reproducible provisioning scripting and all that. And for that reason I need to have a tool that can do that on different host systems like, I can always use laptop here, but the target system might be the external KVM or in all cases, we see VMM now and long-term virtualizer changes as well on laptop in virtual box and all the VSDs we have now or just MI and much more. So the tool we chose is Packer. My Packer is for the next slide, but when I was looking for our installation solutions or whatever, more or less everybody is writing his own installation framework, shell script or whatever, or they use something from GitHub or other stuff on the internet, or something shell script by bash, which is, well, I don't need to tell you, or you really have a provisioning guy on what that one is on holidays or so, so I ended up with Packer and it was last year's European Common Antoine approached me about how there's Packer, I know I'm using it, and I should also work on OpenSD, which the Packer software itself already does, but it needs a bit fiddling around to use VMM, and he asked me if I want to look into it, to have a really native support for VMM. Who was last year here listening to my VATM talk? Oh, I need some. Same problem here, and I was thinking, oh, I was already attacking our Hashicob software, okay, more movie, just to find out that Packer's written in Go, and didn't know any Go, only Go, but that was a nice opportunity to learn Go when it's slow. And I started to tackle it, and Packer itself has a really big advantage that you have single configuration, the other image building will be also in parallel, so you maybe want to create an AMI image, something for Google Cloud Engine, for the original box, all that, and it will run all those build parts in parallel, which gives a nice speed because your OCLIN, for example, is very slow, and you're doing that serialized running around, and they might be over. It's not a conflict management or provisioning tool by itself, it will just reach out if you want to, to add some party software and all that, while you might just be playing or pop and chat as a building, whatever you want, type of a list on some part of one, on the next or second explanation. And that when we go up, and Packer core itself is just an RPC server, so to say, and all the buildable and the other components are so-called plugins, and the core, the distributed Packer software is just one binary, so please, if you look at our playlist of the package, it's just one binary, it gives an open-end Packer, that simple. And the put-in direction is basically one or maybe a second JSON file with variables you can't use in the JSON Packer app or else. So it's a pretty easy setup for the core component. So let's go. Wait. Oh, what the? So we do the good old save our way. So you have the architecture, the actual outcome, if you will, and you must play the wrong, for example, if you want to, or you have an ID and all that. Builds are exactly different tasks to create those architects, and that's using as a whole build-up, which will interact with the RPC, and all that to create the architect. And you have optional provisioners, like I already said, where you can just up the installation itself as finished. You can just run more package at all your Chef recipe or look at it and all that. And then there are post-processes, which care to take those artifacts, like in the true box, the disk image in the data data.json and pile it up into a thought box. So as a way that can use it directly. And that's our RPC. We have templates, like in some other projects, but that's just JSON configuration defining the builders, provisioners, post-processes, and all that in a moment. So I said there are a lot of builders, that's the full list. I just want to open the window as we see for whatever reason. But like I did, you can just write your own blogging to support your virtualizer tissue, but the list is really complete. Anyone having a virtualized environment that's not listed here? I don't think so. If you write your own blogging, you cannot really link it to the main single binary, but you have to put your single binary either in a home directory or in the directory where the packet binaries are. So there would be a package tlday if it would land in your single open bin. And for provisioning within packet, you can use that. So the big players are all in there. And it will check up and solve or just in a channel or if you have a bigger channel environment, I mean, there are shared entities and users here. And that's the unit. So on the OpenVST side, I'm probably most of you don't know those components for VMM, but I'm just adding it here for common root column to generate all that, especially in case my full blogging is interacting here with OpenVST components. So we remember the whole site we need, the steering, the input for the VMs, and VMCTL to interact. System side with VMD and packet blogging is more or less calling out to VMCTLT. And we actually have to create the intended VMs. VMCon would be for network configurations for that. In terms of the blogging, I have no use for that right now, but that might come together today. But there's no use because the package, the packet itself is just a regular user or maybe a build user. But for example, VMD, you need to run this route. And so there is inline handling of the OS. But for some reasons, I cannot interact with the user TTY, so you're typing your password. So you need no pass in the OS.con. So you can't persist typically and time outing too fast. It's only five minutes. So I won't do it. And we are also not getting our own message at that point. We will figure it out the other day. But just if you're writing it, have that in mind that your user enjoys no pass. Additional configuration you will need. So we have a backup and CCDL for the laptop to work. That's only if you need to reach out to the internet like you're doing an HTTP based install from Eversy. You don't need a DOR or your own local whatever. If you do a CD based installation, which I will show in the demo, then you could skip that part. Right, so before the DOR details are coming up, let me press the switch off. You have to come to line. Say? You have to, the last slide. That's settings that you have to go on the host machine that you use. That's on the host machine. This network is what VMM is providing on the host side to have a network link into the VM. And those are unrooted, so you need to match to one whatever it's usable. And that's just an important domain. Of course you have to start with an earbud, add that probably into the plugin itself that can detect if there be VMM running or not, and you will fire it up. What else? What about? So to write a plugin, obviously you need to go. You need to hack it itself as the main core component and git. The dependency for this plugin is around one-time-four gigabyte. Whatever you are doing, you will need to have that space available as well. If you git load my repo, you will get that directory layout, and that's the layout of most of the plugins as well. Some are, let's say, upside down. When I have a main goal in a sub directory and what a main goal files in the main directory, a matter of taste, I would say. There's no specific reason why I'm doing that. And in detail, I'm a little main file just to keep things simple and install. So that's the narrative. VMB is just building a VM, debugging our code, go formatting, working with the dependency tree, testing main and uninstall. The entry point for the plugin is main.go and import, initialize, and register this sub-blogin with the package board. So it knows that there's something out there called a packer-builder of this DBM. You can trigger that by the configuration that the build knows. Oh, I have to talk to that guy. And that's all going over our goal of the scene intervals. And then the server goes into, I thought it would be humanized, but so it's just sitting there waiting for the core to trigger and let it do something. Then in the work-server.go, which is more or less only the complete description of the configuration struct, where all your new configuration and some of your back configuration is defined and how it is accessible in terms of substructs and which types and all that. And since that's a big, bigger, I have put that in our own file, but you could do it in many other drivers as well. So build.go will come up with a so-called driver and then read additional configuration that's like a different configuration like what's the current server of the machine of the host. And then the one part of the plugin will, I call it, organizing all the build steps into so-called steps. So it's like, I have to leave it on the next page. And when the build has finished, it will populate a data structure I could use for a host processor, for example. So I know which artifacts are there and where are they and all that. Since all is parameterized, the host processor could be running five minutes later or something and that's more or less the, let's say, temp storage of configuration information. Drive.go is where the fun part is in terms of interacting with the actual virtualizer, like please create a disk, start this VM, stop the VM, do whatever. Currently, I have an undone function in there. Exactly to be able to reach out from that temporary VM into the Internet or network in general. I need to know which IP address I have so to say on the outside, the capital interface of the host. And the code is just amazing to parse I have config or whatever and I have also currently even just returned 100.64.102 because the code is true or correct for the VM with the ID1. And I was talking to some people actually, it should be possible even for VMCTL as the official administrative tool format that can query VMD in the kernel of Hayward's configuration. Because right now, the configuration in username can only be seen by I have configured the nodes just 10 years. It's okay for a human because we get a description line which VMD belongs to. But from an automation perspective, that's not ideal. So we have done those actual steps for doing that. So we will create a byte, depending on the configuration of the host directory for the artifacts. And then just again like VMCTL to do what is it, create or to create an HD. Create a disk in either raw or view call too. And then run up the VM again based on the configuration we will see the network and how much memory, which kernel, where the slash psdr deal somewhere else. And right now I have a bit of a problem with the debugging error handling and actually successful builds, how to deal with the VM hanging around or exiting too early or error exiting. That means a bit more error handling. So we might end up with a broken pack of build and the VM is still running. I think you have to shut down that first because otherwise we haven't really got ID2. And then the network stuff, as I said, we just fixed return, no more work anymore. So two fixes that should come up pretty soon and that's not the least anymore. And then the most interesting part probably, Packer can be told while the build is running, please bring up an HDD server. And this will bind to more or less random board and I have to gather which part is that and pass it on to the actual boot command. I will see how that looks like and why this is really useful. This build in HDPD kernel run or should run a 480. So the current way, auto install tries to retrieve, install a.com, can work. So you have to more or less fix your L but the IP and the point is a variable you can use in the change department. I will have to look into it this way, auto install tries to retrieve, hostname, install.com, or update.com, or make address and the format. Here is that Packer, the second command, the more is typing this information. So this is everything needed in regards to an ISO based installation, which I can't remember how much memory and all that. And all I was just talking about is exactly that. So.hg.pip and port is a Packer internal variable. My blogging has to get values into it and then you just say which configuration file you want. This configuration file will be looked for in this document, whatever you define it. So that's really a local installation, it's not reaching out to whatever remote thing, so you can have all in one place. The ISO based installation of the way our thing right now works is that it will call VMCTL with dash R, so that will be attached to the VM as a C0. Then you can choose installation as a same source with C0 and what you want. I'm not so good with the demo box, but I have it there. So I have it online, but also in the GitHub ready for a demo cast file, so I can do that offline as well, which I don't have in my version. I'm pausing it for a moment. There's a rock with our BMM and I don't know if it's really possible to get that kind of fix because serial consoles are not meant to be connected twice. So the Stackbook command will attach to the serial console as a TTY. If you are trying to debug your plugin or your other install console setup, just think of when VMCTL connects one, you will get a completely gout output. You cannot fix it. I was trying to make speed settings and whatever. It's not strong because the gout looks just like one speed settings, but Mike told me there's no way you can do it. So I more or less catch the TTY input and output and then Mike and I can do this offline. That's the game of your build and just a block. That's why I'm taming this because the way you ask a cinema, I can come from a second calendar. Why is this just for you? So that's the call. Just pack the build with your chasen. I am going to create the image and then boot up the VM and this is just the serial console output as it starts. And here is no boot because we are booting directly in the BSD.RD. But it's attached at the very moment that VM is coming up. So it tries to do all those automatic fetching of the console.com, but you cannot find it. So it will call back and ask you. And the block end is just typing in the URL and here with the dynamically generated port. And then just running down on information that's in there. It's just a typical OpenSD auto install. One thing if you're wondering, it's not stored. The way it is TTY catch, so to say, where it's based on the life feed here. So you can see like install in base, 6.5, teach set and then you have your progress meter. You can just sit here and you won't see before you ask and then you won't understand all that. Just a more end of it. It's good enough for the environment. It's called under turn install for a reason. Question is going to be green. Why is this running? No, I don't think that's the reason. When Packer connects to the serial port, does Packer come out of intelligence to figure out the device name itself that it needs to back to? Or is it using a helper script or what? It's just if you're starting, we actually got a minusc of getting a direct encounter of that artist with them and just hooking up to them. I'm not going to the device name or whatever. Just grabbing TTY as it comes. Just being informed by the high-priced evidence to track the transfer information in and out of the video under the Packer. What I was talking about with problem with power is I have confidence that just asking BME. It's really depends on the visualizer. It's a machine, readable problem with everything you know about that thing, but that's not here yet. Congrats for borrowing installation. We're not online for no reason. The reason we're voting is actually misleading because the informer, well, it requires a reboot and it will shut down the BME. Well, it tries to reboot by a power cycle, but the BME has no clue of power cycle. The BME wouldn't spring up the BME just again because all the information around it, which can only be found at that moment, so it cannot respan. For now, I have to fix these. I'm just on the other side of the game. I cannot scroll it. Right now it has a static timer of 240 seconds and this one is a bit easy, faster. Currently, Packer is just sitting there for a total of 240 seconds and then it will continue. It should be there. It's not completely. No, it has to be done like, okay, now we are, for a second I will go through the question. I just have to add some driver function which will just hold the MCTL and the moment the BME is gone, I can just go on instead of a timer. So I won't configure a timer, but I will just hold the MCTL when the BME is gone. We're going to hear it. So with this, I have an artifact where I can really notice in the images. Oops. There's a little one-part kick, whatever, but don't just move your points. Just with the network and the local subnet to connect the console and this image file. Now you can see it's just holding up that very nicely. That's what the image is. So you see, obviously, first time though, it's really a trash pool after install. So you're not losing that possibility for chicken egg problems. I can log in with the use information from the chasing file. Actually from the install. So it works and that's it for now. I'm not talking about the demo. For the questions, everybody, please go ahead. So this is great. I could say I want to do 5DN to spin out. So is it possible to say don't spin out 1DN, but spin out 5DN? You wouldn't want to backer word that you would do pass them up locally and you would write it. But you want backer grid to just image and it's been applied to be on the main with that. Okay, so this is only to create the image that you want to create. If you want 5 different images, for example, with different install and comment settings, you adjust this object in tracer. You adjust repeating that with different names and different configurations and then we rush out and try 5DN. Just not yet because of the network thing, but by signup backup, yes. You could do that. If you need 5 running VMs from the same image, then we'll copy it around, of course. Actually, that's a task for the post processor, drag that image in the virtual box world at metadata.json and then power on the box file. You can have multiple of those, for example. Possibilities are way greater in the field of backup. So kind of status of the project is around the VM. I'm sorry, everything is fine besides that thing about I would like to have VMD reporting that configuration stuff, but while that's not publishing, maybe. The plugin itself is from the steps in architecture more or less complete. I have all the part about creating this with other instance, all things for infrastructure, let's say the actual building web server to provide the install.com download. But there's stuff to do to fix. The one thing is, you can tap IP address. Is your pudding request ready? Yeah, I hear. Okay, but I was ready just for lunch, this QCow2 support. So I'm not changing before it was this formal as well, but since two hours or something takes to check, you can use QCow2 as well. And that's what I was just saying about the timeout of server of the VM. If it's gone, the whole thing has finished and then just advanced because timeout would be bad always, like, faster disks, slower disks, faster network. So I'm just adding a package at, what is it, insane dependency tree or so, maybe, add a technical index, putting in all the packages and sending your timeout back again. So, observe it and proceed with the following tasks and just after that. I was talking about that, so if VMD is not running, Packer will just fail around and you might not really have a clue why. I want to have some checks at least, I mean, it's a warning. If VMD is missing, that is an error, it will error out anyway, but if you happen, doesn't have two rules that could be still in catch level. Make it a package that should be worn as an opener for any seasoned package builder or thoughts of a. I want to have more information I can get from the private to be used in even our installers, from over in the JSON file. One feature of our install is you can use a display template or a different display layout, but then other amount points, although that's completely missing and not needed for, let's say, simple VMs. Just on top of that is multiple disks and I'm not thinking about having more than one NIC, VM and configure that and all that. Whatever is coming up, for example, VMD conflict on possibility. And then for next year, taking all those building blocks and information how to make this something like a public load at your fingertips, I need to finish my reference project in terms of grading a record finally, which is still between a mystery and a disaster. Dispreseizing maybe it would not even have that happening because growing as is not the problem, but we calculated display offsets is painful. If you're getting wrong, the thing is so corrupt you cannot repair anything. And for those who know cores or something, or you may not cloud in it and context that if you spin up the VMs in a bigger cloud environment, where you have further auto-configuration of the VM, the project is completely coming up. So that's our look next year or whatever. That's a quick question about integration and matrix. Is the question just making a package or is the question making the package know about VM because of those other providers that are not? Just look at my talk from last year, you see how? So the whole background on OpenGST using VMM is all finished. The problem is I'm still using it with bundle exec, it's a weak code, but having this background movie, what happened? Turn it into a runable binary that's doing that much you get when you just, for example, install the background you're getting binary, that's still in the right thing. And the process from your Ruby built environment to creating a binary distribution isn't open source. Nishu is holding hands on that for reasons I'm not going into. There are several approaches that are dealing with that problem, like I said, it's also an old album, so this one had to come up first because having images ready was a bit more important than background as a package and as a binary distribution. How does this compare to using VMD and creating a binary device and then using that and having columns into it? Just a little bit, what do you do for start with it, but the other way? How much does this go on? I have missed one thing here. No, it's exactly here. We have been trying and playing around with booting the VM with a Pixie-enabled virus, C-Birus, but that's always broken in different ways. My darkening is getting mad over it in the meantime. How about if we could use or change the install script itself, that I can say, hey, you have been booted from disk, but please assume it was a net boot. And then it will start, the configuration will go to DHBD, try to download the install, and all that. This was where this is coming from. And yes, Packer is one way and you can do it a lot of different other ways. And if you don't need that feature or possibilities about parallelized running and all, all good, a lot of people know Packer, but they don't know your script environment or whatever, so you're sure, you don't need that. The development of this thing had some outcome that will help other people who are running Shell script. So that's really... Yeah, Kotlin, C9, so all of here, I started effectively in an app for Clouds where I'm moving in two weeks, finishing up that stuff, it's just perfect for another hack-tall weekend to publish the rough-adjusted hack right now, especially in the development thing. Kotlin, do you say Google or BrabAnode? Yeah. He was adding the module handling because I didn't know that so far. Some more on these little things. And of course, if someone else wants to work on, for example, multi-disk disk drive support, more than welcome. Any more questions? So, this QR code is just that URL. And I'm here tonight at the closing session, of course, in the auction, please, everybody come in. Give me a molecule of charity. And I have a backup slide about ghost stuff, but maybe not. Questions? Peter? Yeah, I want to put this thing in my email, so you can see it's too old, but I didn't recognize it. Oh, yeah, let me go back to... Yeah, hang on. I'll just... Okay. Before this flag was added, if you start from slash BSD, R-D, as per your device, it will not even consider automatic install with our asset. If you call it with minus capital B, net, then it will exactly insert this part with... There is a pixel on the net address. It was not pixie booted. It's failing that. And then the installer will notice, oh, there was a pixie boot. So, our net boot. And we're wrong. It looks like a different code. One more question. Who thinks that this is cool? Oh, thank you. Thanks. By the way, don't forget about the hand-pulled P-Pack-Style on the BSD hand-wrapped side. Oh, thank you very much.
 Okay, welcome to my talk. I'm Philip. I'm a gimmick snore for  about 225 or something years now for three or four years that was obviously developed by the  media.  asking them what we are and what we are.  So this is still what's going to be said about.  So the main thing with all the virtualizers is how to get a good little system image,  you know, network or very weak means like for example, Amazon streaming, drop-wise,  and that system that I can't get to go.  So the least common denominator for our HSS watches files, we have a code that has to pick up the food sector and bring the whole stuff up.  So my tactics especially is I want that infrastructure to grow as I named it,  which means all the stuff we are doing physically in the data center or whatever,  I want to have my laptop itself to simulate all the outprovisioning process.  And that should even be working for sitting in a plane or in a data center with a good parabenic H style of protection.  And that helps me to have reproducible provisioning scripting and all that.  And for that reason I need to have a tool that can do that on different host systems like,  I can always use laptop here, but the target system might be the external KVM or in all cases,  we see VMM now and long-term virtualizer changes as well on laptop in virtual box and all the VSDs we have now or just MI and much more.  So the tool we chose is Packer. My Packer is for the next slide, but when I was looking for our installation solutions or whatever,  more or less everybody is writing his own installation framework, shell script or whatever, or they use something from GitHub or other stuff on the internet,  or something shell script by bash, which is, well, I don't need to tell you, or you really have a provisioning guy on what that one is on holidays or so,  so I ended up with Packer and it was last year's European Common Antoine approached me about how there's Packer, I know I'm using it,  and I should also work on OpenSD, which the Packer software itself already does, but it needs a bit fiddling around to use VMM,  and he asked me if I want to look into it, to have a really native support for VMM. Who was last year here listening to my VATM talk?  Oh, I need some. Same problem here, and I was thinking, oh, I was already attacking our Hashicob software, okay, more movie, just to find out that Packer's written in Go,  and didn't know any Go, only Go, but that was a nice opportunity to learn Go when it's slow.  And I started to tackle it, and Packer itself has a really big advantage that you have single configuration,  the other image building will be also in parallel, so you maybe want to create an AMI image, something for Google Cloud Engine, for the original box, all that,  and it will run all those build parts in parallel, which gives a nice speed because your OCLIN, for example, is very slow,  and you're doing that serialized running around, and they might be over. It's not a conflict management or provisioning tool by itself,  it will just reach out if you want to, to add some party software and all that, while you might just be playing or pop and chat as a building,  whatever you want, type of a list on some part of one, on the next or second explanation.  And that when we go up, and Packer core itself is just an RPC server, so to say, and all the buildable and the other components are so-called plugins,  and the core, the distributed Packer software is just one binary, so please, if you look at our playlist of the package, it's just one binary,  it gives an open-end Packer, that simple. And the put-in direction is basically one or maybe a second JSON file with variables you can't use in the JSON Packer app or else.  So it's a pretty easy setup for the core component.  So let's go. Wait. Oh, what the? So we do the good old save our way.  So you have the architecture, the actual outcome, if you will, and you must play the wrong, for example, if you want to, or you have an ID and all that.  Builds are exactly different tasks to create those architects, and that's using as a whole build-up, which will interact with the RPC,  and all that to create the architect. And you have optional provisioners, like I already said, where you can just up the installation itself as finished.  You can just run more package at all your Chef recipe or look at it and all that.  And then there are post-processes, which care to take those artifacts, like in the true box, the disk image in the data data.json and pile it up into a thought box.  So as a way that can use it directly. And that's our RPC. We have templates, like in some other projects, but that's just JSON configuration defining the builders, provisioners, post-processes, and all that in a moment.  So I said there are a lot of builders, that's the full list. I just want to open the window as we see for whatever reason.  But like I did, you can just write your own blogging to support your virtualizer tissue, but the list is really complete. Anyone having a virtualized environment that's not listed here?  I don't think so.  If you write your own blogging, you cannot really link it to the main single binary, but you have to put your single binary either in a home directory or in the directory where the packet binaries are.  So there would be a package tlday if it would land in your single open bin.  And for provisioning within packet, you can use that. So the big players are all in there.  And it will check up and solve or just in a channel or if you have a bigger channel environment, I mean, there are shared entities and users here.  And that's the unit.  So on the OpenVST side, I'm probably most of you don't know those components for VMM, but I'm just adding it here for common root column to generate all that, especially in case my full blogging is interacting here with OpenVST components.  So we remember the whole site we need, the steering, the input for the VMs, and VMCTL to interact.  System side with VMD and packet blogging is more or less calling out to VMCTLT.  And we actually have to create the intended VMs. VMCon would be for network configurations for that.  In terms of the blogging, I have no use for that right now, but that might come together today.  But there's no use because the package, the packet itself is just a regular user or maybe a build user.  But for example, VMD, you need to run this route.  And so there is inline handling of the OS.  But for some reasons, I cannot interact with the user TTY, so you're typing your password.  So you need no pass in the OS.con.  So you can't persist typically and time outing too fast. It's only five minutes.  So I won't do it. And we are also not getting our own message at that point. We will figure it out the other day.  But just if you're writing it, have that in mind that your user enjoys no pass.  Additional configuration you will need.  So we have a backup and CCDL for the laptop to work.  That's only if you need to reach out to the internet like you're doing an HTTP based install from Eversy.  You don't need a DOR or your own local whatever.  If you do a CD based installation, which I will show in the demo, then you could skip that part.  Right, so before the DOR details are coming up, let me press the switch off.  You have to come to line.  Say?  You have to, the last slide.  That's settings that you have to go on the host machine that you use.  That's on the host machine.  This network is what VMM is providing on the host side to have a network link into the VM.  And those are unrooted, so you need to match to one whatever it's usable.  And that's just an important domain.  Of course you have to start with an earbud, add that probably into the plugin itself that can detect if there be VMM running or not, and you will fire it up.  What else?  What about?  So to write a plugin, obviously you need to go.  You need to hack it itself as the main core component and git.  The dependency for this plugin is around one-time-four gigabyte.  Whatever you are doing, you will need to have that space available as well.  If you git load my repo, you will get that directory layout, and that's the layout of most of the plugins as well.  Some are, let's say, upside down.  When I have a main goal in a sub directory and what a main goal files in the main directory, a matter of taste, I would say.  There's no specific reason why I'm doing that.  And in detail, I'm a little main file just to keep things simple and install.  So that's the narrative. VMB is just building a VM, debugging our code, go formatting, working with the dependency tree,  testing main and uninstall.  The entry point for the plugin is main.go and import, initialize, and register this sub-blogin with the package board.  So it knows that there's something out there called a packer-builder of this DBM.  You can trigger that by the configuration that the build knows.  Oh, I have to talk to that guy. And that's all going over our goal of the scene intervals.  And then the server goes into, I thought it would be humanized, but so it's just sitting there waiting for the core to trigger and let it do something.  Then in the work-server.go, which is more or less only the complete description of the configuration struct, where all your new configuration and some of your back configuration is defined and how it is accessible in terms of substructs and which types and all that.  And since that's a big, bigger, I have put that in our own file, but you could do it in many other drivers as well.  So build.go will come up with a so-called driver and then read additional configuration that's like a different configuration like what's the current server of the machine of the host.  And then the one part of the plugin will, I call it, organizing all the build steps into so-called steps.  So it's like, I have to leave it on the next page.  And when the build has finished, it will populate a data structure I could use for a host processor, for example.  So I know which artifacts are there and where are they and all that.  Since all is parameterized, the host processor could be running five minutes later or something and that's more or less the, let's say, temp storage of configuration information.  Drive.go is where the fun part is in terms of interacting with the actual virtualizer, like please create a disk, start this VM, stop the VM, do whatever.  Currently, I have an undone function in there. Exactly to be able to reach out from that temporary VM into the Internet or network in general.  I need to know which IP address I have so to say on the outside, the capital interface of the host.  And the code is just amazing to parse I have config or whatever and I have also currently even just returned 100.64.102 because the code is true or correct for the VM with the ID1.  And I was talking to some people actually, it should be possible even for VMCTL as the official administrative tool format that can query VMD in the kernel of Hayward's configuration.  Because right now, the configuration in username can only be seen by I have configured the nodes just 10 years.  It's okay for a human because we get a description line which VMD belongs to.  But from an automation perspective, that's not ideal.  So we have done those actual steps for doing that. So we will create a byte, depending on the configuration of the host directory for the artifacts.  And then just again like VMCTL to do what is it, create or to create an HD.  Create a disk in either raw or view call too.  And then run up the VM again based on the configuration we will see the network and how much memory, which kernel, where the slash psdr deal somewhere else.  And right now I have a bit of a problem with the debugging error handling and actually successful builds, how to deal with the VM hanging around or exiting too early or error exiting.  That means a bit more error handling.  So we might end up with a broken pack of build and the VM is still running. I think you have to shut down that first because otherwise we haven't really got ID2.  And then the network stuff, as I said, we just fixed return, no more work anymore.  So two fixes that should come up pretty soon and that's not the least anymore.  And then the most interesting part probably, Packer can be told while the build is running, please bring up an HDD server.  And this will bind to more or less random board and I have to gather which part is that and pass it on to the actual boot command.  I will see how that looks like and why this is really useful.  This build in HDPD kernel run or should run a 480.  So the current way, auto install tries to retrieve, install a.com, can work.  So you have to more or less fix your L but the IP and the point is a variable you can use in the change department.  I will have to look into it this way, auto install tries to retrieve, hostname, install.com, or update.com, or make address and the format.  Here is that Packer, the second command, the more is typing this information.  So this is everything needed in regards to an ISO based installation, which I can't remember how much memory and all that.  And all I was just talking about is exactly that. So.hg.pip and port is a Packer internal variable.  My blogging has to get values into it and then you just say which configuration file you want.  This configuration file will be looked for in this document, whatever you define it.  So that's really a local installation, it's not reaching out to whatever remote thing, so you can have all in one place.  The ISO based installation of the way our thing right now works is that it will call VMCTL with dash R, so that will be attached to the VM as a C0.  Then you can choose installation as a same source with C0 and what you want.  I'm not so good with the demo box, but I have it there.  So I have it online, but also in the GitHub ready for a demo cast file, so I can do that offline as well, which I don't have in my version.  I'm pausing it for a moment.  There's a rock with our BMM and I don't know if it's really possible to get that kind of fix because serial consoles are not meant to be connected twice.  So the Stackbook command will attach to the serial console as a TTY.  If you are trying to debug your plugin or your other install console setup, just think of when VMCTL connects one, you will get a completely gout output.  You cannot fix it. I was trying to make speed settings and whatever.  It's not strong because the gout looks just like one speed settings, but Mike told me there's no way you can do it.  So I more or less catch the TTY input and output and then Mike and I can do this offline. That's the game of your build and just a block.  That's why I'm taming this because the way you ask a cinema, I can come from a second calendar.  Why is this just for you?  So that's the call. Just pack the build with your chasen.  I am going to create the image and then boot up the VM and this is just the serial console output as it starts.  And here is no boot because we are booting directly in the BSD.RD. But it's attached at the very moment that VM is coming up.  So it tries to do all those automatic fetching of the console.com, but you cannot find it.  So it will call back and ask you.  And the block end is just typing in the URL and here with the dynamically generated port.  And then just running down on information that's in there. It's just a typical OpenSD auto install.  One thing if you're wondering, it's not stored. The way it is TTY catch, so to say, where it's based on the life feed here.  So you can see like install in base, 6.5, teach set and then you have your progress meter.  You can just sit here and you won't see before you ask and then you won't understand all that.  Just a more end of it. It's good enough for the environment.  It's called under turn install for a reason.  Question is going to be green. Why is this running? No, I don't think that's the reason.  When Packer connects to the serial port, does Packer come out of intelligence to figure out the device name itself that it needs to back to?  Or is it using a helper script or what?  It's just if you're starting, we actually got a minusc of getting a direct encounter of that artist with them and just hooking up to them.  I'm not going to the device name or whatever. Just grabbing TTY as it comes.  Just being informed by the high-priced evidence to track the transfer information in and out of the video under the Packer.  What I was talking about with problem with power is I have confidence that just asking BME. It's really depends on the visualizer.  It's a machine, readable problem with everything you know about that thing, but that's not here yet.  Congrats for borrowing installation. We're not online for no reason.  The reason we're voting is actually misleading because the informer, well, it requires a reboot and it will shut down the BME.  Well, it tries to reboot by a power cycle, but the BME has no clue of power cycle.  The BME wouldn't spring up the BME just again because all the information around it, which can only be found at that moment, so it cannot respan.  For now, I have to fix these. I'm just on the other side of the game.  I cannot scroll it. Right now it has a static timer of 240 seconds and this one is a bit easy, faster.  Currently, Packer is just sitting there for a total of 240 seconds and then it will continue.  It should be there. It's not completely.  No, it has to be done like, okay, now we are, for a second I will go through the question.  I just have to add some driver function which will just hold the MCTL and the moment the BME is gone, I can just go on instead of a timer.  So I won't configure a timer, but I will just hold the MCTL when the BME is gone.  We're going to hear it.  So with this, I have an artifact where I can really notice in the images.  Oops.  There's a little one-part kick, whatever, but don't just move your points. Just with the network and the local subnet to connect the console and this image file.  Now you can see it's just holding up that very nicely.  That's what the image is.  So you see, obviously, first time though, it's really a trash pool after install.  So you're not losing that possibility for chicken egg problems.  I can log in with the use information from the chasing file.  Actually from the install.  So it works and that's it for now.  I'm not talking about the demo.  For the questions, everybody, please go ahead.  So this is great.  I could say I want to do 5DN to spin out. So is it possible to say don't spin out 1DN, but spin out 5DN?  You wouldn't want to backer word that you would do pass them up locally and you would write it.  But you want backer grid to just image and it's been applied to be on the main with that.  Okay, so this is only to create the image that you want to create.  If you want 5 different images, for example, with different install and comment settings, you adjust this object in tracer.  You adjust repeating that with different names and different configurations and then we rush out and try 5DN.  Just not yet because of the network thing, but by signup backup, yes.  You could do that.  If you need 5 running VMs from the same image, then we'll copy it around, of course.  Actually, that's a task for the post processor, drag that image in the virtual box world at metadata.json and then power on the box file.  You can have multiple of those, for example.  Possibilities are way greater in the field of backup.  So kind of status of the project is around the VM.  I'm sorry, everything is fine besides that thing about I would like to have VMD reporting that configuration stuff, but while that's not publishing, maybe.  The plugin itself is from the steps in architecture more or less complete.  I have all the part about creating this with other instance, all things for infrastructure, let's say the actual building web server to provide the install.com download.  But there's stuff to do to fix. The one thing is, you can tap IP address.  Is your pudding request ready?  Yeah, I hear.  Okay, but I was ready just for lunch, this QCow2 support.  So I'm not changing before it was this formal as well, but since two hours or something takes to check, you can use QCow2 as well.  And that's what I was just saying about the timeout of server of the VM.  If it's gone, the whole thing has finished and then just advanced because timeout would be bad always, like, faster disks, slower disks, faster network.  So I'm just adding a package at, what is it, insane dependency tree or so, maybe, add a technical index, putting in all the packages and sending your timeout back again.  So, observe it and proceed with the following tasks and just after that.  I was talking about that, so if VMD is not running, Packer will just fail around and you might not really have a clue why.  I want to have some checks at least, I mean, it's a warning.  If VMD is missing, that is an error, it will error out anyway, but if you happen, doesn't have two rules that could be still in catch level.  Make it a package that should be worn as an opener for any seasoned package builder or thoughts of a.  I want to have more information I can get from the private to be used in even our installers, from over in the JSON file.  One feature of our install is you can use a display template or a different display layout, but then other amount points,  although that's completely missing and not needed for, let's say, simple VMs.  Just on top of that is multiple disks and I'm not thinking about having more than one NIC, VM and configure that and all that.  Whatever is coming up, for example, VMD conflict on possibility.  And then for next year, taking all those building blocks and information how to make this something like a public load at your fingertips,  I need to finish my reference project in terms of grading a record finally, which is still between a mystery and a disaster.  Dispreseizing maybe it would not even have that happening because growing as is not the problem, but we calculated display offsets is painful.  If you're getting wrong, the thing is so corrupt you cannot repair anything.  And for those who know cores or something, or you may not cloud in it and context that if you spin up the VMs in a bigger cloud environment,  where you have further auto-configuration of the VM, the project is completely coming up.  So that's our look next year or whatever.  That's a quick question about integration and matrix.  Is the question just making a package or is the question making the package know about VM because of those other providers that are not?  Just look at my talk from last year, you see how?  So the whole background on OpenGST using VMM is all finished.  The problem is I'm still using it with bundle exec, it's a weak code, but having this background movie,  what happened?  Turn it into a runable binary that's doing that much you get when you just, for example,  install the background you're getting binary, that's still in the right thing.  And the process from your Ruby built environment to creating a binary distribution isn't open source.  Nishu is holding hands on that for reasons I'm not going into.  There are several approaches that are dealing with that problem,  like I said, it's also an old album, so this one had to come up first because having images ready was a bit more important than background as a package and as a binary distribution.  How does this compare to using VMD and creating a binary device and then using that and having columns into it?  Just a little bit, what do you do for start with it, but the other way?  How much does this go on?  I have missed one thing here.  No, it's exactly here.  We have been trying and playing around with booting the VM with a Pixie-enabled virus, C-Birus,  but that's always broken in different ways.  My darkening is getting mad over it in the meantime.  How about if we could use or change the install script itself, that I can say, hey, you have been booted from disk, but please assume it was a net boot.  And then it will start, the configuration will go to DHBD, try to download the install, and all that.  This was where this is coming from.  And yes, Packer is one way and you can do it a lot of different other ways.  And if you don't need that feature or possibilities about parallelized running and all, all good,  a lot of people know Packer, but they don't know your script environment or whatever, so you're sure, you don't need that.  The development of this thing had some outcome that will help other people who are running Shell script.  So that's really...  Yeah, Kotlin, C9, so all of here, I started effectively in an app for Clouds where I'm moving in two weeks,  finishing up that stuff, it's just perfect for another hack-tall weekend to publish the rough-adjusted hack right now, especially in the development thing.  Kotlin, do you say Google or BrabAnode?  Yeah.  He was adding the module handling because I didn't know that so far.  Some more on these little things.  And of course, if someone else wants to work on, for example, multi-disk disk drive support, more than welcome.  Any more questions?  So, this QR code is just that URL.  And I'm here tonight at the closing session, of course, in the auction, please, everybody come in.  Give me a molecule of charity.  And I have a backup slide about ghost stuff, but maybe not.  Questions?  Peter?  Yeah, I want to put this thing in my email, so you can see it's too old, but I didn't recognize it.  Oh, yeah, let me go back to...  Yeah, hang on.  I'll just...  Okay.  Before this flag was added, if you start from slash BSD, R-D, as per your device, it will not even consider automatic install with our asset.  If you call it with minus capital B, net, then it will exactly insert this part with...  There is a pixel on the net address.  It was not pixie booted.  It's failing that.  And then the installer will notice, oh, there was a pixie boot.  So, our net boot.  And we're wrong. It looks like a different code.  One more question.  Who thinks that this is cool?  Oh, thank you.  Thanks.  By the way, don't forget about the hand-pulled P-Pack-Style on the BSD hand-wrapped side.  Oh, thank you very much.
OpenBSD__add_VMM_to__packer__porting_Go_software_0_107.png OpenBSD__add_VMM_to__packer__porting_Go_software_108_443.png OpenBSD__add_VMM_to__packer__porting_Go_software_444_563.png OpenBSD__add_VMM_to__packer__porting_Go_software_564_1751.png OpenBSD__add_VMM_to__packer__porting_Go_software_1752_1799.png OpenBSD__add_VMM_to__packer__porting_Go_software_1800_2063.png OpenBSD__add_VMM_to__packer__porting_Go_software_2064_2111.png OpenBSD__add_VMM_to__packer__porting_Go_software_2112_2195.png OpenBSD__add_VMM_to__packer__porting_Go_software_2196_2267.png OpenBSD__add_VMM_to__packer__porting_Go_software_2268_2387.png OpenBSD__add_VMM_to__packer__porting_Go_software_2388_2471.png OpenBSD__add_VMM_to__packer__porting_Go_software_2472_2963.png OpenBSD__add_VMM_to__packer__porting_Go_software_2964_3239.png OpenBSD__add_VMM_to__packer__porting_Go_software_3240_3299.png OpenBSD__add_VMM_to__packer__porting_Go_software_3300_3443.png OpenBSD__add_VMM_to__packer__porting_Go_software_3444_3695.png OpenBSD__add_VMM_to__packer__porting_Go_software_3696_3755.png OpenBSD__add_VMM_to__packer__porting_Go_software_3756_5843.png OpenBSD__add_VMM_to__packer__porting_Go_software_5844_8555.png OpenBSD__add_VMM_to__packer__porting_Go_software_8556_12323.png OpenBSD__add_VMM_to__packer__porting_Go_software_12324_12431.png OpenBSD__add_VMM_to__packer__porting_Go_software_12432_17663.png OpenBSD__add_VMM_to__packer__porting_Go_software_17664_20915.png OpenBSD__add_VMM_to__packer__porting_Go_software_20916_21851.png OpenBSD__add_VMM_to__packer__porting_Go_software_21852_22259.png OpenBSD__add_VMM_to__packer__porting_Go_software_22260_23207.png OpenBSD__add_VMM_to__packer__porting_Go_software_23208_23363.png OpenBSD__add_VMM_to__packer__porting_Go_software_23364_27503.png OpenBSD__add_VMM_to__packer__porting_Go_software_27504_32783.png OpenBSD__add_VMM_to__packer__porting_Go_software_32784_37643.png OpenBSD__add_VMM_to__packer__porting_Go_software_37644_40511.png OpenBSD__add_VMM_to__packer__porting_Go_software_40512_43343.png OpenBSD__add_VMM_to__packer__porting_Go_software_43344_43871.png OpenBSD__add_VMM_to__packer__porting_Go_software_43872_43931.png OpenBSD__add_VMM_to__packer__porting_Go_software_43932_43991.png OpenBSD__add_VMM_to__packer__porting_Go_software_43992_44051.png OpenBSD__add_VMM_to__packer__porting_Go_software_44052_44099.png OpenBSD__add_VMM_to__packer__porting_Go_software_44100_44975.png OpenBSD__add_VMM_to__packer__porting_Go_software_44976_46895.png OpenBSD__add_VMM_to__packer__porting_Go_software_46896_48323.png OpenBSD__add_VMM_to__packer__porting_Go_software_48324_51707.png OpenBSD__add_VMM_to__packer__porting_Go_software_51708_51767.png OpenBSD__add_VMM_to__packer__porting_Go_software_51768_51815.png OpenBSD__add_VMM_to__packer__porting_Go_software_51816_51863.png OpenBSD__add_VMM_to__packer__porting_Go_software_51864_51911.png OpenBSD__add_VMM_to__packer__porting_Go_software_51912_52667.png OpenBSD__add_VMM_to__packer__porting_Go_software_52668_52883.png OpenBSD__add_VMM_to__packer__porting_Go_software_52884_53063.png OpenBSD__add_VMM_to__packer__porting_Go_software_53064_53723.png OpenBSD__add_VMM_to__packer__porting_Go_software_53724_54587.png OpenBSD__add_VMM_to__packer__porting_Go_software_54588_56399.png OpenBSD__add_VMM_to__packer__porting_Go_software_56400_57503.png OpenBSD__add_VMM_to__packer__porting_Go_software_57504_61715.png OpenBSD__add_VMM_to__packer__porting_Go_software_61716_63599.png OpenBSD__add_VMM_to__packer__porting_Go_software_63600_63707.png OpenBSD__add_VMM_to__packer__porting_Go_software_63708_66227.png OpenBSD__add_VMM_to__packer__porting_Go_software_66228_70703.png OpenBSD__add_VMM_to__packer__porting_Go_software_70704_71915.png OpenBSD__add_VMM_to__packer__porting_Go_software_71916_71963.png OpenBSD__add_VMM_to__packer__porting_Go_software_71964_72083.png OpenBSD__add_VMM_to__packer__porting_Go_software_72084_72791.png OpenBSD__add_VMM_to__packer__porting_Go_software_72792_72851.png OpenBSD__add_VMM_to__packer__porting_Go_software_72852_72959.png OpenBSD__add_VMM_to__packer__porting_Go_software_72960_73031.png OpenBSD__add_VMM_to__packer__porting_Go_software_73032_74483.png OpenBSD__add_VMM_to__packer__porting_Go_software_74484_74543.png OpenBSD__add_VMM_to__packer__porting_Go_software_74544_74603.png OpenBSD__add_VMM_to__packer__porting_Go_software_74604_75407.png OpenBSD__add_VMM_to__packer__porting_Go_software_75408_75506.png
Okay, welcome to my talk. I'm Philip. I'm a gimmick snore for about 225 or something years now for three or four years that was obviously developed by the media. asking them what we are and what we are. So this is still what's going to be said about. So the main thing with all the virtualizers is how to get a good little system image, you know, network or very weak means like for example, Amazon streaming, drop-wise, and that system that I can't get to go. So the least common denominator for our HSS watches files, we have a code that has to pick up the food sector and bring the whole stuff up. So my tactics especially is I want that infrastructure to grow as I named it, which means all the stuff we are doing physically in the data center or whatever, I want to have my laptop itself to simulate all the outprovisioning process. And that should even be working for sitting in a plane or in a data center with a good parabenic H style of protection. And that helps me to have reproducible provisioning scripting and all that. And for that reason I need to have a tool that can do that on different host systems like, I can always use laptop here, but the target system might be the external KVM or in all cases, we see VMM now and long-term virtualizer changes as well on laptop in virtual box and all the VSDs we have now or just MI and much more. So the tool we chose is Packer. My Packer is for the next slide, but when I was looking for our installation solutions or whatever, more or less everybody is writing his own installation framework, shell script or whatever, or they use something from GitHub or other stuff on the internet, or something shell script by bash, which is, well, I don't need to tell you, or you really have a provisioning guy on what that one is on holidays or so, so I ended up with Packer and it was last year's European Common Antoine approached me about how there's Packer, I know I'm using it, and I should also work on OpenSD, which the Packer software itself already does, but it needs a bit fiddling around to use VMM, and he asked me if I want to look into it, to have a really native support for VMM. Who was last year here listening to my VATM talk? Oh, I need some. Same problem here, and I was thinking, oh, I was already attacking our Hashicob software, okay, more movie, just to find out that Packer's written in Go, and didn't know any Go, only Go, but that was a nice opportunity to learn Go when it's slow. And I started to tackle it, and Packer itself has a really big advantage that you have single configuration, the other image building will be also in parallel, so you maybe want to create an AMI image, something for Google Cloud Engine, for the original box, all that, and it will run all those build parts in parallel, which gives a nice speed because your OCLIN, for example, is very slow, and you're doing that serialized running around, and they might be over. It's not a conflict management or provisioning tool by itself, it will just reach out if you want to, to add some party software and all that, while you might just be playing or pop and chat as a building, whatever you want, type of a list on some part of one, on the next or second explanation. And that when we go up, and Packer core itself is just an RPC server, so to say, and all the buildable and the other components are so-called plugins, and the core, the distributed Packer software is just one binary, so please, if you look at our playlist of the package, it's just one binary, it gives an open-end Packer, that simple. And the put-in direction is basically one or maybe a second JSON file with variables you can't use in the JSON Packer app or else. So it's a pretty easy setup for the core component. So let's go. Wait. Oh, what the? So we do the good old save our way. So you have the architecture, the actual outcome, if you will, and you must play the wrong, for example, if you want to, or you have an ID and all that. Builds are exactly different tasks to create those architects, and that's using as a whole build-up, which will interact with the RPC, and all that to create the architect. And you have optional provisioners, like I already said, where you can just up the installation itself as finished. You can just run more package at all your Chef recipe or look at it and all that. And then there are post-processes, which care to take those artifacts, like in the true box, the disk image in the data data.json and pile it up into a thought box. So as a way that can use it directly. And that's our RPC. We have templates, like in some other projects, but that's just JSON configuration defining the builders, provisioners, post-processes, and all that in a moment. So I said there are a lot of builders, that's the full list. I just want to open the window as we see for whatever reason. But like I did, you can just write your own blogging to support your virtualizer tissue, but the list is really complete. Anyone having a virtualized environment that's not listed here? I don't think so. If you write your own blogging, you cannot really link it to the main single binary, but you have to put your single binary either in a home directory or in the directory where the packet binaries are. So there would be a package tlday if it would land in your single open bin. And for provisioning within packet, you can use that. So the big players are all in there. And it will check up and solve or just in a channel or if you have a bigger channel environment, I mean, there are shared entities and users here. And that's the unit. So on the OpenVST side, I'm probably most of you don't know those components for VMM, but I'm just adding it here for common root column to generate all that, especially in case my full blogging is interacting here with OpenVST components. So we remember the whole site we need, the steering, the input for the VMs, and VMCTL to interact. System side with VMD and packet blogging is more or less calling out to VMCTLT. And we actually have to create the intended VMs. VMCon would be for network configurations for that. In terms of the blogging, I have no use for that right now, but that might come together today. But there's no use because the package, the packet itself is just a regular user or maybe a build user. But for example, VMD, you need to run this route. And so there is inline handling of the OS. But for some reasons, I cannot interact with the user TTY, so you're typing your password. So you need no pass in the OS.con. So you can't persist typically and time outing too fast. It's only five minutes. So I won't do it. And we are also not getting our own message at that point. We will figure it out the other day. But just if you're writing it, have that in mind that your user enjoys no pass. Additional configuration you will need. So we have a backup and CCDL for the laptop to work. That's only if you need to reach out to the internet like you're doing an HTTP based install from Eversy. You don't need a DOR or your own local whatever. If you do a CD based installation, which I will show in the demo, then you could skip that part. Right, so before the DOR details are coming up, let me press the switch off. You have to come to line. Say? You have to, the last slide. That's settings that you have to go on the host machine that you use. That's on the host machine. This network is what VMM is providing on the host side to have a network link into the VM. And those are unrooted, so you need to match to one whatever it's usable. And that's just an important domain. Of course you have to start with an earbud, add that probably into the plugin itself that can detect if there be VMM running or not, and you will fire it up. What else? What about? So to write a plugin, obviously you need to go. You need to hack it itself as the main core component and git. The dependency for this plugin is around one-time-four gigabyte. Whatever you are doing, you will need to have that space available as well. If you git load my repo, you will get that directory layout, and that's the layout of most of the plugins as well. Some are, let's say, upside down. When I have a main goal in a sub directory and what a main goal files in the main directory, a matter of taste, I would say. There's no specific reason why I'm doing that. And in detail, I'm a little main file just to keep things simple and install. So that's the narrative. VMB is just building a VM, debugging our code, go formatting, working with the dependency tree, testing main and uninstall. The entry point for the plugin is main.go and import, initialize, and register this sub-blogin with the package board. So it knows that there's something out there called a packer-builder of this DBM. You can trigger that by the configuration that the build knows. Oh, I have to talk to that guy. And that's all going over our goal of the scene intervals. And then the server goes into, I thought it would be humanized, but so it's just sitting there waiting for the core to trigger and let it do something. Then in the work-server.go, which is more or less only the complete description of the configuration struct, where all your new configuration and some of your back configuration is defined and how it is accessible in terms of substructs and which types and all that. And since that's a big, bigger, I have put that in our own file, but you could do it in many other drivers as well. So build.go will come up with a so-called driver and then read additional configuration that's like a different configuration like what's the current server of the machine of the host. And then the one part of the plugin will, I call it, organizing all the build steps into so-called steps. So it's like, I have to leave it on the next page. And when the build has finished, it will populate a data structure I could use for a host processor, for example. So I know which artifacts are there and where are they and all that. Since all is parameterized, the host processor could be running five minutes later or something and that's more or less the, let's say, temp storage of configuration information. Drive.go is where the fun part is in terms of interacting with the actual virtualizer, like please create a disk, start this VM, stop the VM, do whatever. Currently, I have an undone function in there. Exactly to be able to reach out from that temporary VM into the Internet or network in general. I need to know which IP address I have so to say on the outside, the capital interface of the host. And the code is just amazing to parse I have config or whatever and I have also currently even just returned 100.64.102 because the code is true or correct for the VM with the ID1. And I was talking to some people actually, it should be possible even for VMCTL as the official administrative tool format that can query VMD in the kernel of Hayward's configuration. Because right now, the configuration in username can only be seen by I have configured the nodes just 10 years. It's okay for a human because we get a description line which VMD belongs to. But from an automation perspective, that's not ideal. So we have done those actual steps for doing that. So we will create a byte, depending on the configuration of the host directory for the artifacts. And then just again like VMCTL to do what is it, create or to create an HD. Create a disk in either raw or view call too. And then run up the VM again based on the configuration we will see the network and how much memory, which kernel, where the slash psdr deal somewhere else. And right now I have a bit of a problem with the debugging error handling and actually successful builds, how to deal with the VM hanging around or exiting too early or error exiting. That means a bit more error handling. So we might end up with a broken pack of build and the VM is still running. I think you have to shut down that first because otherwise we haven't really got ID2. And then the network stuff, as I said, we just fixed return, no more work anymore. So two fixes that should come up pretty soon and that's not the least anymore. And then the most interesting part probably, Packer can be told while the build is running, please bring up an HDD server. And this will bind to more or less random board and I have to gather which part is that and pass it on to the actual boot command. I will see how that looks like and why this is really useful. This build in HDPD kernel run or should run a 480. So the current way, auto install tries to retrieve, install a.com, can work. So you have to more or less fix your L but the IP and the point is a variable you can use in the change department. I will have to look into it this way, auto install tries to retrieve, hostname, install.com, or update.com, or make address and the format. Here is that Packer, the second command, the more is typing this information. So this is everything needed in regards to an ISO based installation, which I can't remember how much memory and all that. And all I was just talking about is exactly that. So.hg.pip and port is a Packer internal variable. My blogging has to get values into it and then you just say which configuration file you want. This configuration file will be looked for in this document, whatever you define it. So that's really a local installation, it's not reaching out to whatever remote thing, so you can have all in one place. The ISO based installation of the way our thing right now works is that it will call VMCTL with dash R, so that will be attached to the VM as a C0. Then you can choose installation as a same source with C0 and what you want. I'm not so good with the demo box, but I have it there. So I have it online, but also in the GitHub ready for a demo cast file, so I can do that offline as well, which I don't have in my version. I'm pausing it for a moment. There's a rock with our BMM and I don't know if it's really possible to get that kind of fix because serial consoles are not meant to be connected twice. So the Stackbook command will attach to the serial console as a TTY. If you are trying to debug your plugin or your other install console setup, just think of when VMCTL connects one, you will get a completely gout output. You cannot fix it. I was trying to make speed settings and whatever. It's not strong because the gout looks just like one speed settings, but Mike told me there's no way you can do it. So I more or less catch the TTY input and output and then Mike and I can do this offline. That's the game of your build and just a block. That's why I'm taming this because the way you ask a cinema, I can come from a second calendar. Why is this just for you? So that's the call. Just pack the build with your chasen. I am going to create the image and then boot up the VM and this is just the serial console output as it starts. And here is no boot because we are booting directly in the BSD.RD. But it's attached at the very moment that VM is coming up. So it tries to do all those automatic fetching of the console.com, but you cannot find it. So it will call back and ask you. And the block end is just typing in the URL and here with the dynamically generated port. And then just running down on information that's in there. It's just a typical OpenSD auto install. One thing if you're wondering, it's not stored. The way it is TTY catch, so to say, where it's based on the life feed here. So you can see like install in base, 6.5, teach set and then you have your progress meter. You can just sit here and you won't see before you ask and then you won't understand all that. Just a more end of it. It's good enough for the environment. It's called under turn install for a reason. Question is going to be green. Why is this running? No, I don't think that's the reason. When Packer connects to the serial port, does Packer come out of intelligence to figure out the device name itself that it needs to back to? Or is it using a helper script or what? It's just if you're starting, we actually got a minusc of getting a direct encounter of that artist with them and just hooking up to them. I'm not going to the device name or whatever. Just grabbing TTY as it comes. Just being informed by the high-priced evidence to track the transfer information in and out of the video under the Packer. What I was talking about with problem with power is I have confidence that just asking BME. It's really depends on the visualizer. It's a machine, readable problem with everything you know about that thing, but that's not here yet. Congrats for borrowing installation. We're not online for no reason. The reason we're voting is actually misleading because the informer, well, it requires a reboot and it will shut down the BME. Well, it tries to reboot by a power cycle, but the BME has no clue of power cycle. The BME wouldn't spring up the BME just again because all the information around it, which can only be found at that moment, so it cannot respan. For now, I have to fix these. I'm just on the other side of the game. I cannot scroll it. Right now it has a static timer of 240 seconds and this one is a bit easy, faster. Currently, Packer is just sitting there for a total of 240 seconds and then it will continue. It should be there. It's not completely. No, it has to be done like, okay, now we are, for a second I will go through the question. I just have to add some driver function which will just hold the MCTL and the moment the BME is gone, I can just go on instead of a timer. So I won't configure a timer, but I will just hold the MCTL when the BME is gone. We're going to hear it. So with this, I have an artifact where I can really notice in the images. Oops. There's a little one-part kick, whatever, but don't just move your points. Just with the network and the local subnet to connect the console and this image file. Now you can see it's just holding up that very nicely. That's what the image is. So you see, obviously, first time though, it's really a trash pool after install. So you're not losing that possibility for chicken egg problems. I can log in with the use information from the chasing file. Actually from the install. So it works and that's it for now. I'm not talking about the demo. For the questions, everybody, please go ahead. So this is great. I could say I want to do 5DN to spin out. So is it possible to say don't spin out 1DN, but spin out 5DN? You wouldn't want to backer word that you would do pass them up locally and you would write it. But you want backer grid to just image and it's been applied to be on the main with that. Okay, so this is only to create the image that you want to create. If you want 5 different images, for example, with different install and comment settings, you adjust this object in tracer. You adjust repeating that with different names and different configurations and then we rush out and try 5DN. Just not yet because of the network thing, but by signup backup, yes. You could do that. If you need 5 running VMs from the same image, then we'll copy it around, of course. Actually, that's a task for the post processor, drag that image in the virtual box world at metadata.json and then power on the box file. You can have multiple of those, for example. Possibilities are way greater in the field of backup. So kind of status of the project is around the VM. I'm sorry, everything is fine besides that thing about I would like to have VMD reporting that configuration stuff, but while that's not publishing, maybe. The plugin itself is from the steps in architecture more or less complete. I have all the part about creating this with other instance, all things for infrastructure, let's say the actual building web server to provide the install.com download. But there's stuff to do to fix. The one thing is, you can tap IP address. Is your pudding request ready? Yeah, I hear. Okay, but I was ready just for lunch, this QCow2 support. So I'm not changing before it was this formal as well, but since two hours or something takes to check, you can use QCow2 as well. And that's what I was just saying about the timeout of server of the VM. If it's gone, the whole thing has finished and then just advanced because timeout would be bad always, like, faster disks, slower disks, faster network. So I'm just adding a package at, what is it, insane dependency tree or so, maybe, add a technical index, putting in all the packages and sending your timeout back again. So, observe it and proceed with the following tasks and just after that. I was talking about that, so if VMD is not running, Packer will just fail around and you might not really have a clue why. I want to have some checks at least, I mean, it's a warning. If VMD is missing, that is an error, it will error out anyway, but if you happen, doesn't have two rules that could be still in catch level. Make it a package that should be worn as an opener for any seasoned package builder or thoughts of a. I want to have more information I can get from the private to be used in even our installers, from over in the JSON file. One feature of our install is you can use a display template or a different display layout, but then other amount points, although that's completely missing and not needed for, let's say, simple VMs. Just on top of that is multiple disks and I'm not thinking about having more than one NIC, VM and configure that and all that. Whatever is coming up, for example, VMD conflict on possibility. And then for next year, taking all those building blocks and information how to make this something like a public load at your fingertips, I need to finish my reference project in terms of grading a record finally, which is still between a mystery and a disaster. Dispreseizing maybe it would not even have that happening because growing as is not the problem, but we calculated display offsets is painful. If you're getting wrong, the thing is so corrupt you cannot repair anything. And for those who know cores or something, or you may not cloud in it and context that if you spin up the VMs in a bigger cloud environment, where you have further auto-configuration of the VM, the project is completely coming up. So that's our look next year or whatever. That's a quick question about integration and matrix. Is the question just making a package or is the question making the package know about VM because of those other providers that are not? Just look at my talk from last year, you see how? So the whole background on OpenGST using VMM is all finished. The problem is I'm still using it with bundle exec, it's a weak code, but having this background movie, what happened? Turn it into a runable binary that's doing that much you get when you just, for example, install the background you're getting binary, that's still in the right thing. And the process from your Ruby built environment to creating a binary distribution isn't open source. Nishu is holding hands on that for reasons I'm not going into. There are several approaches that are dealing with that problem, like I said, it's also an old album, so this one had to come up first because having images ready was a bit more important than background as a package and as a binary distribution. How does this compare to using VMD and creating a binary device and then using that and having columns into it? Just a little bit, what do you do for start with it, but the other way? How much does this go on? I have missed one thing here. No, it's exactly here. We have been trying and playing around with booting the VM with a Pixie-enabled virus, C-Birus, but that's always broken in different ways. My darkening is getting mad over it in the meantime. How about if we could use or change the install script itself, that I can say, hey, you have been booted from disk, but please assume it was a net boot. And then it will start, the configuration will go to DHBD, try to download the install, and all that. This was where this is coming from. And yes, Packer is one way and you can do it a lot of different other ways. And if you don't need that feature or possibilities about parallelized running and all, all good, a lot of people know Packer, but they don't know your script environment or whatever, so you're sure, you don't need that. The development of this thing had some outcome that will help other people who are running Shell script. So that's really... Yeah, Kotlin, C9, so all of here, I started effectively in an app for Clouds where I'm moving in two weeks, finishing up that stuff, it's just perfect for another hack-tall weekend to publish the rough-adjusted hack right now, especially in the development thing. Kotlin, do you say Google or BrabAnode? Yeah. He was adding the module handling because I didn't know that so far. Some more on these little things. And of course, if someone else wants to work on, for example, multi-disk disk drive support, more than welcome. Any more questions? So, this QR code is just that URL. And I'm here tonight at the closing session, of course, in the auction, please, everybody come in. Give me a molecule of charity. And I have a backup slide about ghost stuff, but maybe not. Questions? Peter? Yeah, I want to put this thing in my email, so you can see it's too old, but I didn't recognize it. Oh, yeah, let me go back to... Yeah, hang on. I'll just... Okay. Before this flag was added, if you start from slash BSD, R-D, as per your device, it will not even consider automatic install with our asset. If you call it with minus capital B, net, then it will exactly insert this part with... There is a pixel on the net address. It was not pixie booted. It's failing that. And then the installer will notice, oh, there was a pixie boot. So, our net boot. And we're wrong. It looks like a different code. One more question. Who thinks that this is cool? Oh, thank you. Thanks. By the way, don't forget about the hand-pulled P-Pack-Style on the BSD hand-wrapped side. Oh, thank you very much.
writing his own installation framework, shell the package, it's just one binary, it gives an create those architects, and that's using as a have a bigger channel environment, I mean, there VMM is providing on the host side to have a git. The dependency for this plugin is around of the plugins as well. Some are, let's say, that's more or less the, let's say, temp storage going to create the image and then boot up the VM generated port. And then just running down on is a bit easy, faster. Currently, Packer is just server to provide the install.com download. But have some checks at least, I mean, it's a those building blocks and information how to make