 So hello everyone, we just remind you that you can still propose lighting tools and give a vote on these that were already proposed on the board that's in front of B105. Also, don't forget to give feedback for speakers on DevCon website on DevCon.cz. Okay, hi everyone. So yeah, in the space team, we have to make some windows build and to distribute some windows components. And yeah, usually people think it's very complicated to do. So I wanted to use this talk as an opportunity to explain how we are doing it and to actually show you that it's not that difficult. So my name is Christophe Fergero. I've been working at Red Hat in the space team for nearly five years. And so Marc-André will be giving a short demo a bit later. So first start, I'm going to just explain a little bit what SPICE is and which components are making up SPICE and all this stuff. So what is SPICE? Well, it is a protocol which allows you to connect remotely to a desktop. This is usually used to connect to remote virtual machines. But we also have some driver, which you can annex in the driver, which also allows you to connect to an X server running on bare metal and not in a virtual machine. So yeah, this protocol was initially designed by KumaNet, which was bought by Red Hat. Red Hat opened the protocol, opened the client, opened all the components of the SPICE offering from KumaNet. So what are the various components of SPICE? So since it allows you to connect to a VM, so it's related to QMU. So actually we've got a shared library which is used by QMU. And so the shared library is implementing all the remote stuff. So it is the shared library which is taking care of exporting the display so that remote clients can access it. So yeah, this library is called SPICE server. So yeah, if I mention SPICE server later, I'm referring to this library which is running on the host, so server side, which is used by QMU. And then, well, you've got your QMU running with a virtual machine using SPICE. And then you want to connect to it. So we also have to provide some client applications. The one I'm going to talk about in this talk is a Vaguar. But there are actually several different clients because we're actually providing a library which is called SPICE GTK and which is used by different applications. So GNOMEbox is also providing SPICE access. Virtual manager is using it to solar you to access your virtual machine using SPICE. Vinagre is using it and maybe a few other projects. And so in addition to the server part, in addition to the client part, we also provide some drivers, some demons or agents to be installed in the guest. They are not mandatory, but this is useful to provide better integration and to get better performances. So yeah, we've got plenty of components. We cannot only support Linux. We also need to support Windows. So we've got people who want to use the SPICE clients from a Windows machine to access, for example, a Linux VM. And we also have people who want, this is the main use actually, I think, for SPICE. We have people who want to access a Windows virtual machine using Linux clients. So this means we need to have a client running on Windows. And this also means we need to have the guest addition. So we need to have Windows drivers and Windows agents to run in the Windows guests. And so yeah, so about the features of SPICE. So yeah, I said this is remote connection to remote desktop. So what does this mean? So we've got the video, which is exported remotely. So you connect and you see your desktop. So this is fairly obvious. And so when you're connected to this desktop, you can also like change the size of the window of the viewer application. And it will trigger a resize actually on the guest. So the remote desktop will always exactly feed the window of the client. You can also have multiple screens. So either like multiple windows of the client, each corresponding to a physical screen, not physical, but a screen on the guest. And if you have, for example, three screens plugged in your laptop, you connect to a VM where you enabled four screens. And you put it in full screen and like on all the screens on the laptop screen, you will have like all parts of the remote desktop. This supports audio. So both sides. So if the virtual machine is playing some sound, this is going to get out on your laptop. And also you can record some sound on the VM using the microphone from the laptop. So with PICE, you also get USB and smart card through direction. So what I mean by USB redirection is that you have your laptop which is connected to the remote VM. And you plug some USB device. So this can be a USB key. This can be the laptop webcam if it's plugged through USB inside the laptop. This can be basically anything you want. This could be a keyboard or whatever. So from the clients, you can say, OK, I want to reject this device to the VM. And then instead of being available locally on your laptop, you'll be able to use the USB device remotely inside the VM. So you will see your face. If you're using the webcam, you'll see your face inside the VM. If you're using a USB drive, you'll be able to access this to see it remotely on the VM and so on. And we also provide a copy and paste between the client operating system and the remote guest operating system. So this is much better if you want to interact between the two systems. It's much more convenient usually to be able to do that. You've got a URL where you want to paste in your Windows machine because this is a Windows only website, some crazy stuff like that. And we also have some kind of file transfer. For example, dragging a file from the client on the viewer windows like the file is going to get copied to the VM. So how are we doing all these builds for Windows? So it's actually not that hard. I'm going to explain to you how we are doing it in the, not the rest of the talk, but the next few slides. So for the client, as I was saying, the client is a remote viewer. We've got different ones, but I'm going to focus on this one because I think this is the only one that we ship on Windows. So we are using a project which is called MinGW, Minimally Gnu for Windows. The goal of this project is to provide GCC builds on, I mean, the whole GCC tool chain, subinuities and whatever you need to build an application. So this is a version of Windows of GCC which is going to generate Windows executables rather than, I don't know, Linux executables or whatever. So yeah, this is a compiler. This is the tool chain. You've got like some libraries. You've got some headers in order to be able to use these libraries. Yeah, like a whole package of a lot of stuff. There's another project which is also aimed at building Windows executables which is Siegwin. The main difference between Siegwin and MinGW is that Siegwin, they have their own library for like some kind of C library when MinGW is trying to reuse the existing Microsoft libraries. So it's a bit easier to deploy because you can reuse what is already available on the Windows system. So yeah, MinGW, you can target either Windows 32-bit version or 64-bit version. And the important thing is that you don't have to run it on Windows to generate a Windows binary. You can use it as a cross-compiler and this is when things get much easier. So you can run MinGW on your Linux machine and this will generate for you some Windows executables. And this is actually how we are using it to be remodular because this means that you've got all the usual environments. So you use your development environment on Linux, your usual text editor, your usual everything like even your tool chain, the auto tools and everything. You can just use that and then you just build these sources using MinGW instead of GCC. Instead of the standard Linux GCC and in the end you will get a Windows binary. So yeah, in addition to MinGW, so yeah, it's nice to have it but you know if it's only available as a terrible and you have to build it and everything, it's much more complicated. But luckily this is also shipped in at least Fedora, I think Dbian has also some, at least some parts of it. So what does this mean? This means that in Fedora you can easily install the compiler. So you type human install, I think it's MinGW GCC or something like this. So you do this and you get the compiler and the various tools which are needed to do Windows builds. And so it means it's already available from Fedora repositories. But in addition to that, there are also quite a few libraries which were built for Windows. So some DLLs, for example, the Spice Cloud GTK library which I was mentioning, GTK Plus, plenty of libraries. They are also built for Windows and available as Fedora packages. But you will get then a tree with some DLLs and some Windows stuff in it. And then you can just reuse those libraries to build whatever executable you want. And then you can copy the libraries on the executable and everything on Windows and this is going to work. So this means that by using the Fedora MinGW infrastructure, you can get plenty of dependencies already built for Windows and you only have to reuse them to do whatever you want. So this MinGW project in Fedora, this makes things much more easier to use because you just type human install whatever you need and you don't have to build a lot of stuff before being able to start on what you want to do. And so how do we compile the client? This is what I was saying, it's very easy. So if it's from Git, first we need to run autogen.sh and make sure it's not going to run Configure. These days, usually on many projects, you can also use just Autorecon rather than a script and you are done. And then MinGW is providing a script which is wrapping Configure. So in the end, this script is going to call Configure, but it will be called with a lot of environment-variable set and all the parameters that you need in order to do a cross-compilation from Linux to a Windows executable. This command is also working if you run it from a subdirectory. So you can have several subdirectories where you run MinGW 30 to Configure, you run the other one MinGW 64 Configure. In the third one, you run the regular Configure and you make some builds in different directories and so you will have in parallel the various versions of your program which are going to be built. And so after running this script, it's like the only piece of magic I would say in the whole build process. You just run make and after it's done, if you run file, you will see that you have a binary in the Windows format. So this is very nice. So once you have that, one issue you are going to run into is that you need to distribute it because you have this executable, but it's using some GLL, some external ones, most likely it's going to need some data files, some microns, some tons of stuff. And so if you just copy the executable, give it to your friend. This is not going to be enough. So you also need to have a way to have some kind of package that you can install in your user system. So yeah, this is called an installer in the Windows world. And so in order to do this, we use a program which is called MSI Tools. This is used to generate MSI installers. This is a Linux tool, so you can still keep using your Linux environment for that. And so MSI installers, this means Microsoft installer. I think they change the name to Windows installers. But the main goal is just to have some kind of executable program. You double click on it and it's a regular Windows installer. It asks you why do you want to install the program. Then it copies all the files and does everything which is needed for installation. And so yeah, in the MSI Tools, the program which is used for generating the installer, it's called Wixel. It takes its inspiration from a Windows program which is called Wix, WixToolset, which is something, some free project actually from Microsoft, and which I think the recommended way of building installers upstream for Windows. So it's basically Wixel. It takes an XML program, an XML file with a list of files to install, the registry entry to create, the dependency like you can say, okay, I also need to install this DLL and this other DLL and this kind of things. So you're in Wixel and it's going to read the XML file to pick everything which is needed, put all of that in a big file and installer. And the nice thing is that this installer is transactional. That is, it knows how to undo everything it's doing. So this means you get a program to uninstall for free. So this means if you use this MSI installer to install your application, you will also have in the configuration panel when you ask to remove applications, you will also see the, yeah, an installer entry for your application that's doing anything. And so, yeah, we have been using this installer for a while to distribute the viewer and remote viewer for Windows. So this is working nicely. Another tool which I wanted to mention is an SIS. It's also used to generate installers for Windows. It's something different, something a bit older. Initially, it was used, it was created by NerdSoft in order to install WinOp. So fairly old music player on Windows. But it was free software. It has been ported to Linux. You can also use this on Linux to create Windows executables. The main difference with Wixel, MSI tools, is that you are not going to get MSI file. You are just going to get an executable file. And also, you don't provide some XML description of what you want to do. But it's more like a script language. So you can do many more different things. But this also means that to have a standard and basic installer, it can be a bit more work to handle everything in the script language. The reason I'm mentioning it is because for the distribution of the guest drivers, so we talked about the client which is built using MinjW, which is packaged using MSI tools. For the guest drivers, we use NSIS actually to distribute everything. Well, the main reason is that it's not very clear how to install, if it's possible to install drivers using MSI tools. When I say it's not very clear, I mean, it's no one tested it. Maybe some features will be missing from MSI tools and this kind of things. So for the guest tools, we ship some drivers. We ship the agent which is used for copy and paste. We ship the QMU guest agent which is used when the guest goes to sleep or when you want to take a snapshot and things like that. We ship the QXL driver and audit things. They need a bit more sophistication for installation. So for now, we rely on the older installer because since the script language, we have a bit more flexibility on what we can do. But it would be very nice if we were able to also do that using an MSI installer. A few issues I wanted to mention regarding having Windows applications or shipping drivers on Windows. It's easy to build your application for Windows. It's easy to distribute it. But yeah, you also will encounter some Windows-specific issues. We still happen for us actually from time to time for a virtual. So for example, in virtual, we had some issues. We wanted to pass as many keys as possible to the VM. But for example, Windows, it intercepts always control-alt-delete. So we had to do something in order to be able to send control-alt-delete to the VM. Recently, we had a bug about a Japanese user saying, oh, there is this key on the keyboard which is used to switch languages when we type. And it was also not being passed to the VM because we need to call some special API in order to do it. Yeah, among the various things to pay attention to, if you want an icon in your application, well, you will have to add what Windows calls some resources, which will be a small icon embedded in the executable file. So you need some special code if you want to under that. And also something that can be a bit tricky to get right is that on Windows, contrary to Linux, on Linux, you want to install your package and basically you know where everything is going to be. At compile time, you know where you will find your data, you know where everything is going to be, and your application can just use that. On Windows, when you install an application, the first thing that you get is you are asked, okay, where should I install the application? So this means all the data for your application is not going to be in a known location, but it's going to be in some sub directory of the installation location of your application. So you've got some API in nglib to handle that, so basically you have nglib, okay, give me this pass relative to the pass of the executable which is currently being run. So it's not that hard to handle, but you still need some special code to do the right thing and be able to find your application resources. For the drivers, well, yeah, Windows drivers, they are not going to be portable between Windows and Linux, so they are like very Windows specific stuff. A few issues we have with them that so far, I mean, so far. Last time I tried, they were not buildable with MinGW, so we had to rely on the proprietary Microsoft compiler. The main reason for that is that Microsoft is providing a special framework for drivers, and this framework was not available in MinGW. Maybe this has changed recently, but I haven't checked, so yeah, it's a bit sad that we need a special proprietary compiler to build these drivers, and then you have one very specific issue we have with Windows, it's for the graphics drivers, the video drivers. We have one for improved performance, and we need a new one for Windows 8, so they changed the API, we need to use some new API, and unfortunately, finding Windows driver developers in our Linux world is a bit complicated. One also potential issue is about the format of debugging information, which is actually, when you use MinGW, you will get draft debugging information, which is not the format that Visual Studio is using, so this means you cannot use Visual Studio Debugger, you have to use GDB or some related tools. This might be improved and changing since Microsoft has been opening more and more sources. There is some reference code which could be used to write some converters from draft to Microsoft debugging format, even to output this natively, but I'm not sure that this work has been done so far. So that was it for the Windows building of Spice. If you have some questions about this part, I can take some questions now, otherwise we can get back to questions to the end. So any questions? So regarding the Spice Landside improvements, I'm going just to do a short one to slide on this and then Mark Andre will be doing the rest. So recently, or not so recently, which changes did we have in Spice on the client side? So I wanted to mention WebDef sharing. So actually this has been present for a while. What does this mean? This means that the goal is to be able to share a local directory on your laptop and share it with the VM which is running remotely. This makes things much more convenient when you need to exchange documents or files between your laptop with all your everyday files with a VM where you want to run some tests or do some development or something. So the reason for using WebDef is that in Windows and Linux usually it's supported natively so you don't need to install a lot of things in the guest in order to be able to accept the shared folder. And what is currently missing actually is just more advertisement which is what I'm doing now because it's available in VAT Manager. You can add the necessary things to your VM using VAT Manager. It's documented how to do that on the Spice website in the documentation but it's still a little bit hidden and maybe lacking a bit of integration so that it's more widely used. Like having this integrated by default in Ignom boxes for example could be very useful to improve the experience of people. I'm mentioning the SSH agent work because Fidentia was supposed to come and talk about it but he could not attend. Basically he has been working on some path through of this path through but his goal was that if you had some keys unlocked on your local machine that he wanted to be able to use this as well in your guest so that you don't have to type again the password and everything in the guest in order to access remote SSH sessions. The main issue with that, he has some working patches so when he has SSH he needs remote VM he does not get asked for any password because it's already unlocked on the client. His main issue has been upstream integration because he does not want to take over the agent on the guest so he wanted to have some fallback mechanism between the small agents he needs running on the guest in order to do the space communication and he wanted some fallback on the agent which was already running before on the guest which can be for example Ignom Kering and like doing this upstream and getting this integrating upstream is a bit complicated so it's not clear if you are going to be able to provide that or not. And now I'm just giving the microphone to Marc Andre who is going to talk to us about virtue. Can you hear me? Yeah, I guess. Okay. So yeah, initially I was not... I replaced credential basically and Christophe asked me if I could present quickly and demo quickly the status on Virgil. For those who don't know, Virgil is a solution to do GPU accelerated rendering. It's developed mainly by Deverelli and basically how it works is unlike hardware accelerated VGPU solution from Intel or Nvidia and what's not, this one relies only on software components more or less and requires your host to just have open GL I think 2.0 something minimum support so in theory it could work with any hardware although it's not been tested a lot so the way it's implemented it's using Mesa so it's the core and in Mesa you can implement driver in various ways and the coolest way and maybe the easiest way is to use Gallium so it's using Gallium and the way it works is it's kind of translating like the internal Gallium state and commands back to open GL and that's basically the idea behind and then all the rest is like gluing everything so you get on the guest you get a Virgil GPU device that will basically pass all these commands back to the host and if there is like queries or data to send back to the guest and it's also implemented as a regular, very regular like Linux DRM driver and that makes things much easier because then for supporting like Waylon or X even today we don't need to implement another driver in user space we just use the X mode setting driver and thanks to Glamour we get open GL accelerated rendering for X so this is very nice because this is less code for us I mean for like maybe in the future for Spice because Spice is using your QXL driver so it's a different model so this one you know if tomorrow, if today, even today you can see like there is a lot of work going on in Glamour and it will benefit us basically for free so that's really nice and the current status is in the guest the complete GL 3.3 support and Dave has been busy doing a lot of like the next extension so it's actually pretty complete I would say and soonish 4.1 and yeah and there is already 4.4 extension ready and so it's pretty complete and if you run like Piglet test which is like the test suite from OpenGL like the open source OpenGL test suite with like 10,000 of tests and last time I run it was running like more than 95% of tests successfully on my laptop so pretty good so status has been merged in QMU 2.5 in kernel 4.4 it's released and Mesa 11.1 so it's basically more or less released for the past two months and so the remaining stuff basically you can use it today but you know it's not convenient so I don't know if all of this is going to be in the next Fedora release but I hope so I think that's the goal but it's still not so convenient to use because you need to configure everything yourself more or less and also it's only like the QMU command lines sort of and so it would be nice if you know you could just create a VM with boxes and it would be accelerated and you wouldn't even have to think about it so I can... yeah that's it so I can show you basically quickly if you want to see it I can show you we're running today with Pyce because we have patches ready for review they should be soon there so I will... yeah I will show you my laptop if you don't see anything here okay so it's very much my... it's my like development environment more or less so I didn't really like prepare too much this talk okay I will zoom in let me don't see it okay you can see here I want to show you like quickly the command line so command line you know it doesn't change much so we will... of course you need to have like a Verd.io device with Vergeal Enable and then you need to have like Pyce parameters to enable OpenGL 2 and currently you can specify the unique socket like this but in reality all of this you wouldn't have to care you wouldn't have a unique socket listening it's using Nivert somehow so... and then and then I can connect to it currently with just a client like this I give... yeah I can give the unique socket and yeah we are in the desktop so everything work as expected more or less you know so it's hard to see like the difference between a regular Spice client but a Spice driver I can run some OpenGL stuff my favorite is GenMark because I want to see like the performance so it's accelerated and and one thing I really like is it's intensive using shaders for example this one ShaderToy if you don't know it's really putting your driver to the knees because it's compiling like complicated shaders and the driver are not so good at compiling shaders actually and they can take some time minutes even freezing your pages and so it's... if I have network maybe I don't I mean I can run something so someone favor it's game like yeah so and you can see like people like to do that so you can disconnect and reconnect obviously yeah it's running okay so we won't see the shader I guess oh yeah okay so it takes a while to compile but if you test it on your like natively it's also that long I mean sometimes it's really long in general I think the performance we are you could say on average maybe 50% from native in the best case close to native and in some of the worst case like 30% from native but it's pretty decent like if you run this on your laptop without VM you get like 30% more performance but it's still quite close I mean and the benefit is I mean you get like accelerated OpenGL anyway so it's an even like I don't know what's this some bug I guess so yeah that's it if you have any question now okay so I didn't talk about that yeah it's currently only local and there is plan how to do this remotely using GPU encoding but currently it's only local and yes you can run several VMs it's no issue some of the issue will come up like quickly because like GPU scheduling and so on they are not but it's the same with traditional application so it's not clear how like things are being shared between a VM and you cannot like you know allocate that amount of resource of GPU to a VM and so on so so this this kind of things will come up I don't know this is more like low level and it's it's true for any OpenGL application anyway so yeah so for spice in general I mean spice in general doesn't really care much is it's complicated like I mean it uses I mean large screen are like using a lot of memory and and it's raising now and QXL so what was the limit with QXL again I don't remember because I've not been involved with that for a while yeah so I can just say a word for Virgil it's not I mean there is no limitation basically it's whatever your hardware handles as far as I know it's like if your OpenGL context can create like really really large frame buffer then no issue it's just a matter of like how big your frame buffer can be off-screen file buffer yeah with Virgil or with QXL with QXL it's all a matter of the amount of memory you want to dedicate to it usually we put the limit at four simultaneous monitors which is already quite a bit of memory if you want to go with a full HD monitor with four full HD monitors maybe you can use more than that but then you would need to no? okay so what is the question exactly I mean like the type of scenario basically if you have all your VMs running on a corporate network running on internal IPs and you want people out of the corporate network being able to accept the VMs like people in the hotel wanted to connect to the remote VM then they would just connect to the VM through the proxy for example I guess even internally you may want to isolate the VM network from the rest of the of your corporate network or things like that so we had one last question here and then we'll be running out of time so this was developed at the time of USB2 and I think most of the standard was supported for USB3 we might be missing a few small bits but yeah so USB2 devices are going to work and I think some USB3 devices are also working nicely yeah so we are running out of time so thanks everyone