 So, I mentioned there is an overt plugin for Barrios now, and I'll give a short idea of what it is, what it does. You might have noticed I haven't had time to colorize the slide. This one is copied from the other one. I think most of you were here, I'm just going to skip it. First question, what is overt? Coming to overt.org, overt is a free open source virtualization solution for your entire enterprise. So it's the upstream project for record virtualization. If you use that, everything I tell you about overt is also true for record virtualization. It basically runs virtual machines by using KVM on virtually any number of hosts. So if you have a data center to run with a lot of machines, you can use overt to manage a lot of virtual machines basically like vSphere. Also in multiple data centers and multiple virtual data centers. So again, think vSphere. It is mostly web-managed, which is a good thing because you don't need some Windows client or whatever. And it has a decent REST API, which really makes it fun to work with if you want to implement stuff. So what is the overt plugin for Barrios? It's a Python plugin for the Barrios FileDemon, so the FileDemon is a component that takes the backups and does the restores on the end. It's written in Python and is able to backup and restore virtual machines in Overt, exactly. It uses something that's called the overt Python SDK, which is really great because you don't even have to talk to the REST API yourself. You get an auto-generated Python SDK to do so. So implementing this, yeah, actually we have no idea how hard it was to implement because it's a contribution from one of our partners. It was written by Carlos Rodriguez at Eurotux. But when we looked at it, it looked like it was really easy to implement because of the Python API, which was really simple. Yeah, so how does it work? If you want to take a backup, first you take a snapshot. So when the backup job in Barrios starts and the director sets up everything and the FileDemon starts to talk to the SearchDemon, the plugin will actually look if the virtual machine is there, take a snapshot of the virtual machine, we'll take a backup of the VM configuration so you always know what were the settings of the VM. We'll connect to the ImageIODemon, which is a specific thing to Overt to interact with all kinds of images. And we'll back up the snapshot's disk contents. You can optionally exclude disks from the snapshots. So if you just want, for example, to snapshot the system disk but not some data disk, you can exclude the data disk, it won't be in the snapshot, it won't be in the backup, and it won't be restored when you restore. Finally, you remove the snapshot because you don't want a lot of snapshots. Restoring, even simpler. You start a restore job, the plugin takes a look at what you want to restore, takes a look at using the API if the virtual machine is there, if it's there and you said you want to override. Sorry, it's going to override. If it's not there, it's going to create the VM with a backup configuration. If it's there and you didn't say override, it's going to bail out and say, no, sorry, I'm not going to override your live virtual machine. The VM has to be shut down to do this. So the chances of accidentally overwriting with a restore are rather small. And then the next interesting thing that happens is the disk contents is restored, which basically is connecting to the image IO, moving all the data over there. So in the end, this is a really simple process and there are not many things that can break here. If you don't want to restore onto your live system or you just want to take a look, the alternative route is to just restore a plain configuration file and image files. So if you backup an overt machine, your overt cluster is broken, whatever, and you cannot restore to this, but you need the virtual machine now or you need a file from there, you can restore the disk image file and use guestfish or whatever to take a look at the contents or you can import it to some other system or use it just with plain KVM, whatever you think. There are, however, a few limitations. Right now, there's no backup of the VM state. So you can do a snapshot that also captures the actual status of the running virtual machine. And we cannot do that right now because it was out of scope for the project. But it can probably be added. What happens for us is it's a disk snapshot, which the VIRT-IO tools on the guest, no, sorry, the QEMO guest tools on the guest machine will try to kiosk the disk access, then the disk will snapshot it and then you have a somewhat crash-clean snapshot. So when the machine comes up, it may think it had crashed. And right now, it's only possible to take a full backup, which is a problem of the API. So over the problem always is that features like this have to work up the whole large letter somewhat like this. So the change block tracking was introduced in KVM quite some time ago. Then it went into LibVirt. And now that it's in LibVirt, it starts to go into Overt. So this took quite a long time. I have no idea in what status this is right now, but there is a talk tomorrow in the virtualization IAS death room by Daniel Erez. It's called Back to the Future. And it's going to talk about what the API for taking incremental backups of Overt and Red Hat virtualization will look like. And once there is a stable API and we get something that works, we will most probably implement incremental and maybe even differential backups for this and lift this current limitation. Also, there are probably a lot more limitations. We just didn't think about it because we haven't heard of the use cases. The plugin is new. People have not used it very much. It has been tested, but it's not in the wild. It's just included in the release we did yesterday. So it's very, very new. If there are problems with it or you run into issues or there are limitations, please tell us, get involved, talk to us. Get on the user's mailing list. If you're happy with the product, if you're unhappy with the product, no matter, just talk to us. If you can and want to check out stuff on GitHub and as I already said, get in touch with us on the next events where we are. Thank you. I'm sorry I didn't colorize the slides. I didn't find the time for that. This one in black and white. Anybody has any questions? Is that something you support as a company? Yes. Basically, if it is in the master branch of the repository, there's 99% chance it will be commercially supported in the next release. Okay. Can you do some integration from physical to virtual? This doesn't work because for physical machines, you cannot take images of physical machines right now with Barrios. Even if you could, the image formats are incompatible. That's nothing we can fix because for us, it's just a data stream we ingest and we give it back to the API. VMware does its stuff, Overt does its stuff. If these were compatible, probably yes. For example, maybe if you backup from Overt, you can restore a QCAL image and you can then import that into some other KVM solution. But physical to virtual and stuff like this, not really. I don't think it's in scope for us. If you need to do that, take a look at RIA. It's a great project for disaster recovery and it also supports all kinds of... I'm going to make an image of this machine, no matter what it is, and just put it on another machine and get it up and running. No. Same thing. Yeah, no problem. Yes. The point is, in the end, there is no community addition. There is one source base where we build the commercial packages and also the community packages. The only difference is we only provide the first major release as a binary. If you want to get the patch updates, you can get a subscription from us or you can build them yourselves or have somebody build them for you. Preferably, we would like to do this because... Yeah, any more questions? No? Then? Yeah? I think they're related to the director, for example. Do you have a limit of how many clients you can run? Yes, but not a practical one. Between? Big int, which is, I think... Yeah? No, technically there's nothing tested. The problem you have is usually not the director being unable to scale, but mostly either the database behind the director or your scheduling, because... The scheduler was my concern. Yes. It depends. In theory, unlimited. In practice, I can't tell you. So, time's up. Thank you very much.