Re: [Qemu-devel] Re: Spice project is now open
On 12/12/09 23:35, Dor Laor wrote: 2. VDI (Virtual Desktop Interface) http://www.spice-space.org/vdi.html It's an abstraction layer for graphics/keyboard/mouse/sound /usb/serial. We need it anyway regardless of spice. What is our user like to switch from vnc to SDL on runtime? It's good for usb-over-ip for remoting, for various mouse modes, etc. What does spice need which isn't present in qemu today? You can start qemu with both sdl and vnc enabled. Graphic output is sent to both. Keyboard and mouse input is accepted from both. Sound via vnc works too. What doesn't work: usb + chardevs (i.e. serial console), so we need some interface here. For graphics spice probably needs a different interface than the existing for a stupid framebuffer with copyrect op. I don't see a need for new keyboard/mouse/sound interfaces though. cheers, Gerd
Re: [Qemu-devel] Re: Spice project is now open
Gerd Hoffmann wrote: On 12/12/09 23:35, Dor Laor wrote: 2. VDI (Virtual Desktop Interface) http://www.spice-space.org/vdi.html It's an abstraction layer for graphics/keyboard/mouse/sound /usb/serial. We need it anyway regardless of spice. What is our user like to switch from vnc to SDL on runtime? It's good for usb-over-ip for remoting, for various mouse modes, etc. What does spice need which isn't present in qemu today? You can start qemu with both sdl and vnc enabled. Graphic output is sent to both. Keyboard and mouse input is accepted from both. Sound via vnc works too. What doesn't work: usb + chardevs (i.e. serial console), so we need some interface here. For graphics spice probably needs a different interface than the existing for a stupid framebuffer with copyrect op. I don't see a need for new keyboard/mouse/sound interfaces though. (Looking at spice-space.org), VDI seems to be a whole lot more than just a graphics thing. It looks a plugin interface for qemu as it incorporates things like fd registration, timer registration, etc. I don't think it's really needed verses just integrating spice support directly. I don't quite understand the relationship between spice and vdi though. If libspice implements a VDI interface directly and that's what it expects people to write against verses vdi existing solely for interaction with qemu. If the later is the case, then it's probably an unnecessary abstraction. If the former is the case, then it's just the api we have to live with. Of course, you could use something like VDI to separate out the vnc server into a more well defined module. However, I'd suggest separating that modularity effort from the integration of spice. Either do that starting with the vnc server, then add spice, or add spice with tight integration, and then build a common interface. The later is probably better since it gives you more clear requirements for the interface. Regards, Anthony Liguori
Re: [Qemu-devel] Re: Spice project is now open
On 12/14/2009 04:42 PM, Anthony Liguori wrote: I think it's a bit trickier though because ideally you would want to use the vnc protocol to negotiate which vm you're connecting to. Right, of course. If the client can no longer choose the target using its port number, it has to select it in some other way. That implies that you actually need to hand over the fd in a setup state. It's complicated by any encryption protocol too. Yes - need to pass the encryption state. Hopefully the crypto stacks support this. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Re: Spice project is now open
On Mon, Dec 14, 2009 at 08:42:12AM -0600, Anthony Liguori wrote: Avi Kivity wrote: On 12/13/2009 01:46 AM, Anthony Liguori wrote: Dan Berrange and I have been talking about being able to move VNC server into a central process such that all of the VMs can have a single VNC port that can be connected to. This greatly simplifies the firewalling logic that an administrator has to deal with. That's a problem I've already had to deal with for our management tools. We use a private network for management and we bridge the VNC traffic into the customers network so they can see the VGA session. But since that traffic can be a large range of ports and we have to tunnel the traffic through a central server to get into the customer network, it's very difficult to setup without opening up a mess of ports. I think we're currently opening a few thousand just for VNC. Seems to me the best way to handle this is to run an accept() in a server and hand the resulting fd to the vnc server in qemu using ... wait for it ... SCM_RIGHTS. I'm just happy every time someone lobs a question into the air that can be answered using SCM_RIGHTS. That's actually a great idea made even better by the use of SCM_RIGHTS :-) I think it's a bit trickier though because ideally you would want to use the vnc protocol to negotiate which vm you're connecting to. That implies that you actually need to hand over the fd in a setup state. It's complicated by any encryption protocol too. The model I had in mind was for the proxy to define a VNC extension that allows the client to query what 'desktops' are available and request switching between them at any time. The list of desktop would of course be authorized per client, and strong authentication is a must for this. Any time a switch was made, the RFB protocol would return to the 'ServerInit' state. The idea is that you should not assume a homogenous environment, and you really don't want to fall down to the lowest common denominator of extensions, nor have the proxy doing re-encoding on the FB data updates. Returning to the ServerInit state allowing the client to re-negotiate the set of encodings for the new desktop, and so the proxy can be fairly stateless and while needing to understand the wire protocol, it can just pass through the actual FB update data unchanged. The combo of the an extension for switching desktops on the fly and the encryption state problem doesn't really seem to fit with passing the VNC FD over with SCM_RIGHTS. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Re: [Qemu-devel] Re: Spice project is now open
On Mon, Dec 14, 2009 at 04:53:07PM +0200, Avi Kivity wrote: On 12/14/2009 04:42 PM, Anthony Liguori wrote: I think it's a bit trickier though because ideally you would want to use the vnc protocol to negotiate which vm you're connecting to. Right, of course. If the client can no longer choose the target using its port number, it has to select it in some other way. That implies that you actually need to hand over the fd in a setup state. It's complicated by any encryption protocol too. Yes - need to pass the encryption state. Hopefully the crypto stacks support this. There's no mechanism for this in the SASL libraries. With GNUTLS there is the ability to preserve negotiated session state from one TLS conenection and used it upon opening the next connection to fast-track the handshake phase. This doesn't allow you to pass the state for an existing connection to a new process though and have it carry on Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Re: [Qemu-devel] Re: Spice project is now open
On 12/14/2009 05:17 PM, Daniel P. Berrange wrote: Yes - need to pass the encryption state. Hopefully the crypto stacks support this. There's no mechanism for this in the SASL libraries. With GNUTLS there is the ability to preserve negotiated session state from one TLS conenection and used it upon opening the next connection to fast-track the handshake phase. This doesn't allow you to pass the state for an existing connection to a new process though and have it carry on This sucks. But we can ask the client to reauthenticate. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Re: Spice project is now open
Avi Kivity wrote: On 12/14/2009 05:17 PM, Daniel P. Berrange wrote: Yes - need to pass the encryption state. Hopefully the crypto stacks support this. There's no mechanism for this in the SASL libraries. With GNUTLS there is the ability to preserve negotiated session state from one TLS conenection and used it upon opening the next connection to fast-track the handshake phase. This doesn't allow you to pass the state for an existing connection to a new process though and have it carry on This sucks. But we can ask the client to reauthenticate. Or instead of passing the socket file descriptor, pass over a socketpair and encrypt the traffic in the server. The encryption requires no knowledge of the protocol so it can be done easily enough in the server. You're already paying the cost for copying the data. Adding in one copy shouldn't be the end of the world. Regards, Anthony Liguori
Re: [Qemu-devel] Re: Spice project is now open
Avi Kivity wrote: You can still implement this with SCM_RIGHTS. Authenticate, select guest, drop tls, pass fd to qemu, authenticate, hack hack hack, drop tls, pass fd back to proxy, goto 10. Here's how I'd envision this working. Start qemu with: qemu -vnc proxy:/path/to/unix/domain/socket We connect to /path/to/unix/domain/socket and wait to recv file descriptors after telling the server it's name and what protocol version it supports. We treat each received file descriptor as a new connection. We use do full protocol with no specific authentication. The server runs and opens /path/to/unix/domain/socket. Whenever a client connects to the server socket, it does protocol negotiation using the least common denominator of protocol versions given it. We use a protocol extension to list and negotiate which client to connect to. Once that's been established, we send a socketpair() over the appropriate domain socket, and do appropriate negotiation to get us up to the ServerInit stage. We use a combination of DesktopResize and WMVi in the server to get the client at the appropriate state to match the ServerInit. We then (in the server) blindly proxy any data from the qemu instance to the client (encrypting it if necessary). We won't need to reencode any traffic in this model and it's pretty reasonable from a UI perspective. In fact, if we use a helper, we can probably have an even better command line for qemu. Regards, Anthony Liguori
Re: [Qemu-devel] Re: Spice project is now open
On Mon, 2009-12-14 at 15:10 +, Daniel P. Berrange wrote: The model I had in mind was for the proxy to define a VNC extension that allows the client to query what 'desktops' are available and request switching between them at any time. The list of desktop would of course be authorized per client, and strong authentication is a must for this. Any time a switch was made, the RFB protocol would return to the 'ServerInit' state. The idea is that you should not assume a homogenous environment, and you really don't want to fall down to the lowest common denominator of extensions, nor have the proxy doing re-encoding on the FB data updates. Returning to the ServerInit state allowing the client to re-negotiate the set of encodings for the new desktop, and so the proxy can be fairly stateless and while needing to understand the wire protocol, it can just pass through the actual FB update data unchanged. The combo of the an extension for switching desktops on the fly and the encryption state problem doesn't really seem to fit with passing the VNC FD over with SCM_RIGHTS. I actually did a demo of this before, in a slightly different context. The idea was: - vnc client connects to gdm, which spawned a Xvnc(A) server with a gdm auth dialog - user logs in and if you've an Xvnc server already, it would move the client connection to the original Xvnc(B) server - first, gdm would tell the (A) to sync it's state; (A) would stop sending updates, flush its zlib/tls streams and pass gdm the current state of the connection - e.g. the protocol version, pixel format, supported encodings etc. - then gdm would pass the connection fd using SCM_RIGHTS to the existing Xvnc along with the connection state, and (B) would pick up the connection - from the users point of view, they were logged instantly back into their old session Simply flushing the encryption/compression state was the key, but AFAIR clients needed a trivial fix to allow them to properly handle the server flushing the stream. The alternative was to somehow get the server to dump its encryption/compression state and pass that to the existing server, but that seemed quite difficult when I looked. SCM_RIGHTS rule ... this was definitely one of the most fun hacks I've done :-) Cheers, Mark. p.s. - I'm sure I can dig up the code, here are some diffs that look like older than what I remember finishing: http://www.gnome.org/~markmc/code/gdm-vnc-support.patch http://www.gnome.org/~markmc/code/test-gnutls-client-close-restart.c http://www.gnome.org/~markmc/code/test-gnutls-server-close-restart.c http://www.gnome.org/~markmc/code/test-zlib.c http://www.gnome.org/~markmc/code/vnc-4.0b5-vncviewer-tls.diff http://www.gnome.org/~markmc/code/vnc-managed.patch http://www.gnome.org/~markmc/code/vnc-tls.patch
Re: [Qemu-devel] Re: Spice project is now open
On Sat, 12 Dec 2009 18:18:01 -0600 Anthony Liguori anth...@codemonkey.ws wrote: Andrea Arcangeli wrote: On Sat, Dec 12, 2009 at 05:52:49PM -0600, Anthony Liguori wrote: This is the bit that confuses me. VNC is not a driver. When I say it cannot crash the guest, I mean that if the VNC server makes a mistake, there may be a SEGV in qemu or it may just result in a VNC client seeing corruption. The guest does not see a bad VGA register content though or something like that. VNC is a host driver or backend service or whatever you want to call it. VNC does not have migration state because it has no guest visible state. Again, a guest crash because of qlx interaction is not what I mean. And the reason I wasn't even thinking about this scenario is that the kind of paravirt-driver related guest crash you are talking about, if it can happen, can happen even if spice lib in the qemu side lives in a separate address space. Yes, that's absolutely true. This is why this case of pure guest crash through qlx is not relevant to decide if to have spice lib inside our outside of qemu address space, I think that is more about the qlx driver and not spice on the qemu side. The guest visible state thing has nothing to do with where it lives. Sorry if that's gotten mixed in with this discussion. The guest visible state is just the qxl device. It is pci device..., and it migrate just like any other pci device inside qemu... What am I missing here?
Re: [Qemu-devel] Re: Spice project is now open
On 12/12/2009 07:28 PM, Anthony Liguori wrote: I think the question I was raising was not whether Spice could handle X, but that given the things you can do with X, is all of Spice really needed. IOW, would we get 99% of the way there with Xv accelerated overlays and Xrender based compositing for VNC? Suppose only 1% of spice is needed to support X. Given that we wish to support Windows well, does it matter? I understand X better than I understand Windows so it's easier for me to understand things as they relate to X. My original question was how much better is Spice support for Windows than it is for X. If Spice is really designed for Windows and does really well for it, that's great. I'm just trying to understand what it's good for and what it's not good for. Spice was in fact designed primarly for Windows. But given that graphics cards were designed for Windows and X tries to support graphics cards well, we should have a pretty good match. Offscreen bitmaps and spice's client-side rendering model should work particularly well, I think. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Re: Spice project is now open
On 12/13/2009 01:46 AM, Anthony Liguori wrote: Dan Berrange and I have been talking about being able to move VNC server into a central process such that all of the VMs can have a single VNC port that can be connected to. This greatly simplifies the firewalling logic that an administrator has to deal with. That's a problem I've already had to deal with for our management tools. We use a private network for management and we bridge the VNC traffic into the customers network so they can see the VGA session. But since that traffic can be a large range of ports and we have to tunnel the traffic through a central server to get into the customer network, it's very difficult to setup without opening up a mess of ports. I think we're currently opening a few thousand just for VNC. Seems to me the best way to handle this is to run an accept() in a server and hand the resulting fd to the vnc server in qemu using ... wait for it ... SCM_RIGHTS. I'm just happy every time someone lobs a question into the air that can be answered using SCM_RIGHTS. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Re: Spice project is now open
Dan Berrange and I have been talking about being able to move VNC server into a central process such that all of the VMs can have a single VNC port that can be connected to. This greatly simplifies the firewalling logic that an administrator has to deal with. That's a problem I've already had to deal with for our management tools. We use a private network for management and we bridge the VNC traffic into the customers network so they can see the VGA session. But since that traffic can be a large range of ports and we have to tunnel the traffic through a central server to get into the customer network, it's very difficult to setup without opening up a mess of ports. I think we're currently opening a few thousand just for VNC. Actually my plan was to have a VNC proxy server, that sat between the end user the real VNC in QEMU. Specifically I wanted to allow for a model where the VNC server end users connected to for console servers was on a physically separate host from the VMs. I had a handful of use cases, mostly to deal with an oVirt deployment where console users could be from the internet, rather than an intranet. - Avoiding the need to open up many ports on firewalls - Allow on the fly switching between any VMs the currently authenticated user was authorized to view without opening more connections (avoids needing to re-authenticate for each VM) - Avoid needing to expose virtualization hosts to console users, since console users may be coming in from an untrusted network, or even the internet itself. - Allow seemless migration where proxy server simply re-connects to the VM on new host, without the end user VNC connection ever noticing. Hi, Having a single well known port to connect to the VMs on an host would be *awesome* as having one port per VM is sooo 1980's in terms of manageability/secureability. Actually both use cases described above are needed IMO: - it would be great to have some sort of server running locally on the VM host so that you only have one open port on the VM host itself [1]. - it would be very usefull to have some sort of proxy mechanism that would allow redirection from a single host acting as a gateway between networks (be it internal or external networks). The two of them could interact nicely with one connecting to the other if needed: ___VM_Host_proxy_Host_ _client_machine_ |1 | 2 | | 3 | | |VM - local server |- | proxy | - | client | |||__| |__| I think one of the most important thing is that the proxy and the local server must behave exactly the same way and provide the same features (that is the protocol used on connection 2 should be the same as the one for connection 3). This allow the client to work the same independently of the configuration/topology. The proxy allows for enterprise class features whereas the local server is enough for a small virtual infrastructure or even a single machine setup, but that should be transparent to the clients. I guess there must exist a way to route the connection to the correct VM, so there should be something similar to the HTTP Host request-header to identify the VM the client wants to connect to [2]. Of course SASL support is mandatory but I guess Dan planned it anyway :) Ideally there would be some sort of negociation mechanism so the client can ask what protocol (vnc, spice, ...) they want to use (if possible dynamically within a session if a user change its location/if its need evolve). Obviously both shouldn't need to be run as root. I guess the proxy should be a project on his own and not part of qemu since it is more of an enterprise feature while the local server could be added to qemu? Of course since there are some common features, it would probably make sense to share some code. Concerning the proxy, there are all sorts of goodies I would expect from it (on top of seamless migration and on-the-fly switching) : - flexibility in the choice of the authorization backend - since it is a SPOF, it would be nice for it to work as a cluster (in active/passive with failover or better as an active/active cluster) Since this proxy can be used as a connection broker to either physical or virtual machines, load-balancing and session management features would be nice. Of course in a perfect world this wouldn't be a single company project ;) My humble 2 cents as an operations person, Gildas -- [1] firewalling is also important on internal networks if you work in a large environment, and having a single port makes it easier to understand what is going on when diagnosing issues. [2] You also need to point to the correct host. How you want to publish the VM/VM Host association so the proxy can route is an interesting problem on its own, especially since VM can (and will) migrate. There are probably many ways to do this including DNS SRV, LDAP, local
Re: [Qemu-devel] Re: Spice project is now open
Hi everyone, On Fri, Dec 11, 2009 at 09:44:02PM -0600, Anthony Liguori wrote: A typical scenario is someone develops a closed source plugin, but does not distribute it with the original piece of software thinking that they aren't creating a derived work because there's no combination. Creation of derived work of a GPL'd program isn't defined like this. You can ask confirmation to IBM lawyers. Even ignoring the explicit allow Linus gave (initially for already existing x86 drivers coming from other proprietary OS that had more drivers than linux at the time), it was meant for software written for other OS and ported over to be dynamic linked into the kernel, so clearly not creating a derivative work as the binary existed already for other OS. This has been abused, and later EXPORT_MODULE_GPL was added too... Even if anybody can remove the _GPL tag with any GPL'd patch, without necessarily creating a derivative work or breaking the GPL by removing that _GPL suffix. However if your module only works after you remove a couple of _GPL suffixes that rings an huge bell that you are breaking the GPL and everyone will look if that really is a derivative work or not. GCC is not the best example since it's support for plugins are relatively new. It's bad for users. They start using a plugin for one version and they really like it, they want to update to a new version of the base program and now their plugin no longer works. The plugin has gone unmaintained and now they have to choose between the plugin and updating the base program. If plugin is dead and unmaintained I guess it wasn't so useful after all... besides it's all GPL so he can maintain it himself. Libs APIs also are upgraded and they stop building and you got to upgrade the program too in order to use the new lib. It doesn't matter if this is called a plugin, static or dynamic lib, in raw terms it's just a function that changed its arguments, how the function .text is loaded into the address space is technicality. I don't think the kernel is an example of it working smoothly. It's a constant source of frustration for users and people are constantly doing ugly things wrt licensing. There are lots of less stable GPL'd module drivers too, it's not just nvidia, so what? Besides the tainting flag that avoids some of the time waste of the few abuses of the interface, CONFIG_MODULE=y is clearly a net win and removing pluggable modules would be insanity. In life few things are black and white and 100% improvements, but when the benefit greatly exceeds the downsides, it's fairly silly to use the few downsides as an argument to reject it. It'd be like refusing to catch a plane because it could crash in the middle of the ocean. In a previous email you said: -- Historically, we have not supported multiple display mechanisms favoring making one mechanism as good as it can be. Supporting both Spice and VNC would go against this policy. It's not -- There's no such thing as a policy in open source, this is not a committee, code rulez in GPL'd world, everything else is irrelevant. About the discussion of improving VNC, this code has to change and move so fast (you can see already requests from Alexander to split the features to allow remote usb from remote qlx, it's expectable code to change for the better to support more obscure features than 99% of userbase cares about as it goes open), it's huge, it's unreasonable to pretend to make official modifications to VNC protocol every time we do a small change to the protocol to please Alexander or anybody other reasonable wishes of the day, even vnc could eventually reach equivalent speedup (which is debatable too). Going the vnc route and official feature requests to extend the protocol is a dead hand IMHO, all you can argue is spice or something else separate from vnc. Likely the spice protocol should be left free to float for a while so all graphics people can put their hands on it and improve it. Open sourcing it is going to inevitably improve spice protocol. There is no hardware involvement, no lock-in, no lack of specs, this is an area where open source can shine against proprietary world. But policies, licenses and in general political arguments must be left void and irrelevant and we must stick to technical discussions about code. Once things settled down and protocol is stable it is very reasonable to expect a VNC export to enable/disable so legacy vnc clients can still be used on qlx guest even if they will lose most of the benefits. But worrying and discussing it now is too early. It would be like pretending to provide a git-svn importer before git was actually usable... Overall, it's awesome SPICE has been finally released Open Source, even if in only in tarball form so far. I hope splitting the tarball in patches is also feasible... ;) and it will be done, but clearly it's a clumsy work and so I guess it will take a bit of time so there's no particular reason to worry
Re: [Qemu-devel] Re: Spice project is now open
Andrea Arcangeli wrote: About the discussion of improving VNC, this code has to change and move so fast (you can see already requests from Alexander to split the features to allow remote usb from remote qlx, it's expectable code to change for the better to support more obscure features than 99% of userbase cares about as it goes open), it's huge, it's unreasonable to pretend to make official modifications to VNC protocol every time we do a small change to the protocol to please Alexander or anybody other reasonable wishes of the day, even vnc could eventually reach equivalent speedup (which is debatable too). Going the vnc route and official feature requests to extend the protocol is a dead hand IMHO, all you can argue is spice or something else separate from vnc. What I really want is a high quality paper comparing Spice to other options (like VNC) with performance graphs demonstrating why it's so much better. A paper isn't really necessary but what I'd like to see is that level of detailed comparison. Spice has been closed source for a long time. For those that have been involved with Spice development, I'm sure you understand very well why it's so wonderful, but for the rest of us, Spice didn't exist until yesterday so it's going to take a little bit for us to all understand what actually about it makes it special. And with respect to the spice protocol, what's the model around making changes to the specification? Is it just submit a patch to the spice project? You complain about VNC's extensibility, but so far, we have no idea whether it's even possible to extend Spice. Given the interactions so far, I'm a little concerned about how well we can influence the protocol. If spice really needs to be able to evolve on it's own, what would it take for spice to be implementable from an external process? What level of interaction does it need with qemu? As long as we can prevent any device state from escaping from qemu, I'd be very interested in a model where spice lived entirely in a separate address space. Regards, Anthony Liguori
Re: [Qemu-devel] Re: Spice project is now open
Paolo Bonzini wrote: On 12/12/2009 04:34 AM, Anthony Liguori wrote: Firefox uses that extensively, for example to render tiled backgrounds (though probably GTK user interface elements can do so less successfully). Yes, but this is just a single application. The point is that these things are not as widely standardized on X as they are on Windows. They are standardized (Xrender) and there are high-level de facto standard APIs (Cairo or the Qt equivalent). Cairo is pretty new and not widely used by applications yet. But even Xrender is very limited compared to all of the things that GDI supports. If it's just a matter of offloading Xrender, you could implement compositing in VNC fairly easily. Regarding compositing, this is done via OpenGL so even though it is true that nothing goes through X calls, it is also true that everything does go though a high-level API which can be sent on the wire (cfr. AIGLX). Right, but 3D is a different topic. Spice doesn't address this today. Actually, compositing might really be where a protocol like SPICE shines, since it does not generate nearly as many expose events, and since you do not have to resend occluded contents on the wire any time someone raises a window. It's a trade off. If you're sending each windows contents verses sending the visible screen, you're incurring an upfront cost assuming interaction will be improved. This is something that I'd really like to see perf data on because. I have no idea how SPICE performs now, but there's definitely nothing in a modern X Windows desktop that it cannot deal with. The only negative point it might have compared to Windows is IMO the rendering of text. I think the question I was raising was not whether Spice could handle X, but that given the things you can do with X, is all of Spice really needed. IOW, would we get 99% of the way there with Xv accelerated overlays and Xrender based compositing for VNC? BTW, can someone split out these VDI patches and get them on the list? Maybe at least an ETA of when that will happen. I think it would make this whole discussion a lot more fruitful if we had more context.. Regards, Anthony Liguori
Re: [Qemu-devel] Re: Spice project is now open
On Sat, Dec 12, 2009 at 09:03:26AM -0600, Anthony Liguori wrote: Spice has been closed source for a long time. For those that have been involved with Spice development, I'm sure you understand very well why it's so wonderful, but for the rest of us, Spice didn't exist until yesterday so it's going to take a little bit for us to all understand what actually about it makes it special. I personally wasn't involved but I've seen it running with video fullscreen and I don't know the comparison with rdesktop as I never used it but I know the comparsion with vnc too well ;). It has to get even faster and avoid decoding the compressed stream on the server. project? You complain about VNC's extensibility, but so far, we have no idea whether it's even possible to extend Spice. Given the interactions so far, I'm a little concerned about how well we can influence the protocol. Well this is open source, so you know, anybody can change it, fork it, takeover it, simply. And it's in the interest of everyone to help in converging on the best SPICE protocol. If spice really needs to be able to evolve on it's own, what would it take for spice to be implementable from an external process? What level of interaction does it need with qemu? As long as we can prevent any device state from escaping from qemu, I'd be very interested in a model where spice lived entirely in a separate address space. Funny thing is I think it's already in a separate process! ;) (you know it wasn't open source until recently so...), but now that you mention it, I think it should be changed to not be in a separate process... Linux is monolithic, KVM is the monolithic way (xen is the microkernel slow way), I think you don't need to worry about sharing spice libs in the same address space. We want to make it as fast as feasible on the server side. A separate address space forces tlb flushes, mm switches and screw performance and spice is all about performance. We've already a pipe to connect server and client, we should try to avoid having two pipes as much as possible and have a single exit to qemu spice ring and send directly to spice client with virtio instead of sending to separate process that eventually sends to remote spice client. Like 99% of microkernel designs they're very wasteful, what good it does that the network is still up and running when you lost access to your harddisk because the sata driver crashed? Or to have access to sata disk but network driver crashed and you can't reach the system anymore. Yeah there are corner cases where they can be useful but those won't use linux kernel or monolitich kvm design in the first place and they will run dogslow and they'll demonstrate math correctness all software running on the bare metal with math which means you can't patch the software anymore until math people recomputes. We're not in that environment (luckily). In this case keeping it separate means the desktop remains reachable through network but virtual graphics card, virtual mouse and stuff crashed, if somebody uses qlx that means the VM has to be rebooted anyway. Ok, it won't risk to create disk corruption but in practice the slowdown it creates it's not worth paying compared to the minor risk that you really end up corrupting a bit in qcow2 cluster bitmap in a way that doesn't crash the VM but silently corrupts data. If something if I had to pay slowdown for higher reliability of disk I/O it would be much better to move qcow2 and the I/O stack to its own address space so it's protected from all the rest too... plus qcow2 is a lot less performance critical than network graphics! Plus there's valgrind and all that userland stuff to trap memory corruption, orders of magnitude easier to debug than kernel random corruption (that over time we fix too and so we keep run at max speed). Having the thing modular at runtime not only at ./configure time (loadable dynamically into qemu address space) OTOH is great idea, so you can disable the module and verify the crashes go away without having to rebuild.
Re: [Qemu-devel] Re: Spice project is now open
On 12/12/2009 05:11 PM, Anthony Liguori wrote: I have no idea how SPICE performs now, but there's definitely nothing in a modern X Windows desktop that it cannot deal with. The only negative point it might have compared to Windows is IMO the rendering of text. I think the question I was raising was not whether Spice could handle X, but that given the things you can do with X, is all of Spice really needed. IOW, would we get 99% of the way there with Xv accelerated overlays and Xrender based compositing for VNC? Suppose only 1% of spice is needed to support X. Given that we wish to support Windows well, does it matter? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
Re: [Qemu-devel] Re: Spice project is now open
Avi Kivity wrote: On 12/12/2009 05:11 PM, Anthony Liguori wrote: I have no idea how SPICE performs now, but there's definitely nothing in a modern X Windows desktop that it cannot deal with. The only negative point it might have compared to Windows is IMO the rendering of text. I think the question I was raising was not whether Spice could handle X, but that given the things you can do with X, is all of Spice really needed. IOW, would we get 99% of the way there with Xv accelerated overlays and Xrender based compositing for VNC? Suppose only 1% of spice is needed to support X. Given that we wish to support Windows well, does it matter? I understand X better than I understand Windows so it's easier for me to understand things as they relate to X. My original question was how much better is Spice support for Windows than it is for X. If Spice is really designed for Windows and does really well for it, that's great. I'm just trying to understand what it's good for and what it's not good for. Regards, Anthony Liguori
Re: [Qemu-devel] Re: Spice project is now open
Andrea Arcangeli wrote: On Sat, Dec 12, 2009 at 09:03:26AM -0600, Anthony Liguori wrote: Spice has been closed source for a long time. For those that have been involved with Spice development, I'm sure you understand very well why it's so wonderful, but for the rest of us, Spice didn't exist until yesterday so it's going to take a little bit for us to all understand what actually about it makes it special. I personally wasn't involved but I've seen it running with video fullscreen and I don't know the comparison with rdesktop as I never used it but I know the comparsion with vnc too well ;). It has to get even faster and avoid decoding the compressed stream on the server. I can run video full screen with VNC on my local lan. In fact, that's the benchmark I use to do perf measurements with gtk-vnc. I'm not saying that VNC handles video as well as Spice, I can pretty much guarantee that it doesn't :-) If spice really needs to be able to evolve on it's own, what would it take for spice to be implementable from an external process? What level of interaction does it need with qemu? As long as we can prevent any device state from escaping from qemu, I'd be very interested in a model where spice lived entirely in a separate address space. Funny thing is I think it's already in a separate process! ;) (you know it wasn't open source until recently so...), but now that you mention it, I think it should be changed to not be in a separate process... Linux is monolithic, KVM is the monolithic way (xen is the microkernel slow way), I think you don't need to worry about sharing spice libs in the same address space. We want to make it as fast as feasible on the server side. A separate address space forces tlb flushes, mm switches and screw performance and spice is all about performance. We've already a pipe to connect server and client, we should try to avoid having two pipes as much as possible and have a single exit to qemu spice ring and send directly to spice client with virtio instead of sending to separate process that eventually sends to remote spice client. Like 99% of microkernel designs they're very wasteful, what good it does that the network is still up and running when you lost access to your harddisk because the sata driver crashed? Or to have access to sata disk but network driver crashed and you can't reach the system anymore. Yeah there are corner cases where they can be useful but those won't use linux kernel or monolitich kvm design in the first place and they will run dogslow and they'll demonstrate math correctness all software running on the bare metal with math which means you can't patch the software anymore until math people recomputes. We're not in that environment (luckily). In this case keeping it separate means the desktop remains reachable through network but virtual graphics card, virtual mouse and stuff crashed, if somebody uses qlx that means the VM has to be rebooted anyway. If Spice can crash a guest, that indicates to me that Spice is maintaining guest visible state. That is difficult architecturally because if we want to do something like introduce a secure sandbox for running guest visible emulation, libspice would have to be part of that sandbox which would seem to be difficult. The VNC server cannot crash a guest by comparison. FWIW, I don't see any reason why Spice couldn't be made to be separate from guest emulation. I think it would just require the right interfacing in qemu. I think that's purely an implementation detail. Regards, Anthony Liguori
Re: [Qemu-devel] Re: Spice project is now open
On Sat, 12 Dec 2009 11:40:21 -0600 Anthony Liguori anth...@codemonkey.ws wrote: FWIW, I don't see any reason why Spice couldn't be made to be separate from guest emulation. I think it would just require the right interfacing in qemu. I think that's purely an implementation detail. The QXL device is one of the core compoments of spice..., how can you separate it from the guest visible state? (it is pci device) Regards, Anthony Liguori
Re: [Qemu-devel] Re: Spice project is now open
Izik Eidus wrote: On Sat, 12 Dec 2009 11:40:21 -0600 Anthony Liguori anth...@codemonkey.ws wrote: FWIW, I don't see any reason why Spice couldn't be made to be separate from guest emulation. I think it would just require the right interfacing in qemu. I think that's purely an implementation detail. The QXL device is one of the core compoments of spice..., how can you separate it from the guest visible state? (it is pci device) How does live migration work then? Do you have to query libspice for it's state? Does it return an opaque blob? How can it integrate with VMState since libspice doesn't have any knowledge of something like VMState? Regards, Anthony Liguori
Re: [Qemu-devel] Re: Spice project is now open
On Sat, 12 Dec 2009 13:26:30 -0600 Anthony Liguori anth...@codemonkey.ws wrote: Izik Eidus wrote: On Sat, 12 Dec 2009 11:40:21 -0600 Anthony Liguori anth...@codemonkey.ws wrote: FWIW, I don't see any reason why Spice couldn't be made to be separate from guest emulation. I think it would just require the right interfacing in qemu. I think that's purely an implementation detail. The QXL device is one of the core compoments of spice..., how can you separate it from the guest visible state? (it is pci device) How does live migration work then? Do you have to query libspice for it's state? Does it return an opaque blob? How can it integrate with VMState since libspice doesn't have any knowledge of something like VMState? QXL transfer the device states by itself using qemu migration mechanisem. The spice server just need that the pci memory (and the qxl ram/rom state) will be migrate. (From the point of view of guest visible state) All this guest visible states are transfered by the qxl device using qemu. Regards, Anthony Liguori
Re: [Qemu-devel] Re: Spice project is now open
On 12/12/2009 07:40 PM, Anthony Liguori wrote: If Spice can crash a guest, that indicates to me that Spice is maintaining guest visible state. That is difficult architecturally because if we want to do something like introduce a secure sandbox for running guest visible emulation, libspice would have to be part of that sandbox which would seem to be difficult. The VNC server cannot crash a guest by comparison. That's not accurate: https://bugzilla.redhat.com/show_bug.cgi?id=505641 - (CVE-2009-3616) CVE-2009-3616 Remote VNC client can cause any QEMU VNC server to crash with a double-free and again: https://bugzilla.redhat.com/show_bug.cgi?id=495646 - Get segfault when changing vnc password Why vnc server code should be protected and spice server not? In addition, like Izik said, the qxl device/driver pair is a must. QXL is a great addition even in 'old' vnc mode since it supports lots of goodies. In addition for caching it also allows s3 state (qxl d3) for the OS, unlike Cirrus. More VNC bugs that we run into: https://bugzilla.redhat.com/show_bug.cgi?id=507880 - qemu hangs during VNC connection from RHEVM https://bugzilla.redhat.com/show_bug.cgi?id=490344 - QEMU: Cannot VNC to a VM if a VNC is already opened to it https://bugzilla.redhat.com/show_bug.cgi?id=497524 - QEMU: Early BIOS error message cannot be seen after reboot in VNC https://bugzilla.redhat.com/show_bug.cgi?id=501263 - KVM: VNC screen is sometimes corrupted (at boot?) If we'll break spice to components we have the following (and I'm not a spice expert): 1. QXL device/driver pair Is anyone debate we should have it in qemu? We should attach it SDL and vnc backend too anyway. 2. VDI (Virtual Desktop Interface) http://www.spice-space.org/vdi.html It's an abstraction layer for graphics/keyboard/mouse/sound /usb/serial. We need it anyway regardless of spice. What is our user like to switch from vnc to SDL on runtime? It's good for usb-over-ip for remoting, for various mouse modes, etc. 3. Spice server Shared library, in the same address space of qemu (like vnc server). Very sophisticated peace of code. 4. Spice client - independent. So #1 shouldn't run into any opposition. We can discuss why #2 is good, the layering separation between guest/host seems good idea to me. As for #3, this is a library. If we have #2, one can even use a separate address space for sanity reasons. From my experience with spice (through all Red Hat QA), 99.9% of failures originated in qemu.. HTH, Dor FWIW, I don't see any reason why Spice couldn't be made to be separate from guest emulation. I think it would just require the right interfacing in qemu. I think that's purely an implementation detail. Regards, Anthony Liguori
Re: [Qemu-devel] Re: Spice project is now open
On 12/12/2009 09:48 PM, Izik Eidus wrote: On Sat, 12 Dec 2009 13:26:30 -0600 Anthony Liguorianth...@codemonkey.ws wrote: Izik Eidus wrote: On Sat, 12 Dec 2009 11:40:21 -0600 Anthony Liguorianth...@codemonkey.ws wrote: FWIW, I don't see any reason why Spice couldn't be made to be separate from guest emulation. I think it would just require the right interfacing in qemu. I think that's purely an implementation detail. The QXL device is one of the core compoments of spice..., how can you separate it from the guest visible state? (it is pci device) How does live migration work then? Do you have to query libspice for it's state? Does it return an opaque blob? How can it integrate with VMState since libspice doesn't have any knowledge of something like VMState? QXL transfer the device states by itself using qemu migration mechanisem. The spice server just need that the pci memory (and the qxl ram/rom state) will be migrate. (From the point of view of guest visible state) All this guest visible states are transfered by the qxl device using qemu. In addition, the src spice server notifies the client on the migration execution and at the end of the migration it commands it to switch to the destination. It even passes a one time password session key. Does vnc has that? If you're interested of having a basic vnc mode, it will be much more easier, cleaner and faster to do the opposite, like Mark suggested - Add a basic vnc mode to spice. That said, it shouldn't be a merge criteria, let's start with qxl and vdi, and than the spice library. Regards, Anthony Liguori
Re: [Qemu-devel] Re: Spice project is now open
On Sat, Dec 12, 2009 at 11:40:21AM -0600, Anthony Liguori wrote: If Spice can crash a guest, that indicates to me that Spice is That's not what I meant, anything in qemu address space can crash a guest not just spice, even qcow2 could crash a guest, you just need to *vaddr_in_guest_physical_space = 0 through a corrupted pointer (corrupted pointers are very rare, gcc is very pedantic, there are tools to trap those but they historically happened a few times in the kernel), but when I said it I didn't in mind crashing just the guest, I meant corrupting qemu memory itself through a different corrupted vaddr, but it is the same risk, you could flip a bit in a buffer header holding ext4 metadata in the guest physical address space or flip a bit in qcow2 cluster bitmap, it doesn't make a difference both could result in fs corruption in an extremely unlikely scenario (and that extremely unlikely scenario is the only one where the microkernel design would eventually payoff, where you get the graphics and mouse hosed, but the guest sill is reachable through the network). I simply meant spice should live in the same address space where the other virtio drivers are living for the same reasons (performance), it's no different. Izik already answered the other part. Thanks, Andrea
Re: [Qemu-devel] Re: Spice project is now open
Dor Laor wrote: On 12/12/2009 07:40 PM, Anthony Liguori wrote: If Spice can crash a guest, that indicates to me that Spice is maintaining guest visible state. That is difficult architecturally because if we want to do something like introduce a secure sandbox for running guest visible emulation, libspice would have to be part of that sandbox which would seem to be difficult. The VNC server cannot crash a guest by comparison. That's not accurate: Cannot crash the *guest*. It can crash qemu but it's not guest visible. IOW, the guest never interacts directly with the VNC server. The difference matters when it comes to security sandboxing and live migration. If we'll break spice to components we have the following (and I'm not a spice expert): 1. QXL device/driver pair Is anyone debate we should have it in qemu? We should attach it SDL and vnc backend too anyway. 2. VDI (Virtual Desktop Interface) http://www.spice-space.org/vdi.html FYI, www.spice-space.org is not responding for me. It's an abstraction layer for graphics/keyboard/mouse/sound /usb/serial. We need it anyway regardless of spice. What is our user like to switch from vnc to SDL on runtime? It's good for usb-over-ip for remoting, for various mouse modes, etc. 3. Spice server Shared library, in the same address space of qemu (like vnc server). Very sophisticated peace of code. The bit I've been trying to understand is whether the Spice server interacts directly with a guest or not. I assume I'd be able to gather that from the VDI interfaces but the server's been down since this morning. So #1 shouldn't run into any opposition. We can discuss why #2 is good, the layering separation between guest/host seems good idea to me. As for #3, this is a library. If we have #2, one can even use a separate address space for sanity reasons. From my experience with spice (through all Red Hat QA), 99.9% of failures originated in qemu.. Where #3 lives is purely a function of what level of integration it needs with qemu. There may be advantages to having it external to qemu. I actually think we should move the VNC server out of qemu... Dan Berrange and I have been talking about being able to move VNC server into a central process such that all of the VMs can have a single VNC port that can be connected to. This greatly simplifies the firewalling logic that an administrator has to deal with. That's a problem I've already had to deal with for our management tools. We use a private network for management and we bridge the VNC traffic into the customers network so they can see the VGA session. But since that traffic can be a large range of ports and we have to tunnel the traffic through a central server to get into the customer network, it's very difficult to setup without opening up a mess of ports. I think we're currently opening a few thousand just for VNC. For VNC, to make this efficient we just need a shared memory transport that we can use locally. I doubt the added latency will matter as long as we're not copying data. Of course, Spice is a different thing altogether. I have no idea whether it makes sense for Spice like it would for VNC. But I'd like to understand if the option is available. Regards, Anthony Liguori
Re: [Qemu-devel] Re: Spice project is now open
Andrea Arcangeli wrote: On Sat, Dec 12, 2009 at 11:40:21AM -0600, Anthony Liguori wrote: If Spice can crash a guest, that indicates to me that Spice is That's not what I meant, anything in qemu address space can crash a guest not just spice, even qcow2 could crash a guest, you just need to *vaddr_in_guest_physical_space = 0 through a corrupted pointer (corrupted pointers are very rare, gcc is very pedantic, there are tools to trap those but they historically happened a few times in the kernel), but when I said it I didn't in mind crashing just the guest, I meant corrupting qemu memory itself through a different corrupted vaddr, but it is the same risk, you could flip a bit in a buffer header holding ext4 metadata in the guest physical address space or flip a bit in qcow2 cluster bitmap, it doesn't make a difference both could result in fs corruption in an extremely unlikely scenario (and that extremely unlikely scenario is the only one where the microkernel design would eventually payoff, where you get the graphics and mouse hosed, but the guest sill is reachable through the network). I simply meant spice should live in the same address space where the other virtio drivers are living for the same reasons (performance), it's no different. This is the bit that confuses me. VNC is not a driver. When I say it cannot crash the guest, I mean that if the VNC server makes a mistake, there may be a SEGV in qemu or it may just result in a VNC client seeing corruption. The guest does not see a bad VGA register content though or something like that. VNC is a host driver or backend service or whatever you want to call it. VNC does not have migration state because it has no guest visible state. When you compare Spice to a virtio driver, that implies to me that it does interact directly with the guest. In fact, when you have a driver passing high level commands to Spice, you would think that the status of these commands would be pending state, no? Let's say the guest sends a fill rectangle command and the Spice server sends that to a client. The Spice server needs to know when the client has finished that (maybe not, but let's assume it does) so there is now a pending request that someone has to keep track of. If you do a savevm or a live migration, or the client disconnects, the state of that request has to be saved somewhere (unless you tell the guest that the client has disconnected which is how Xen handles pv device migration). So that's what I'm trying to understand. How far does the guest's visibility go? Is the guest totally ignorant of anything other than QXL? If so, that's good, and I'm very happy about it :-) Regards, Anthony Liguori
Re: [Qemu-devel] Re: Spice project is now open
On Sat, Dec 12, 2009 at 05:52:49PM -0600, Anthony Liguori wrote: This is the bit that confuses me. VNC is not a driver. When I say it cannot crash the guest, I mean that if the VNC server makes a mistake, there may be a SEGV in qemu or it may just result in a VNC client seeing corruption. The guest does not see a bad VGA register content though or something like that. VNC is a host driver or backend service or whatever you want to call it. VNC does not have migration state because it has no guest visible state. Again, a guest crash because of qlx interaction is not what I mean. And the reason I wasn't even thinking about this scenario is that the kind of paravirt-driver related guest crash you are talking about, if it can happen, can happen even if spice lib in the qemu side lives in a separate address space. This is why this case of pure guest crash through qlx is not relevant to decide if to have spice lib inside our outside of qemu address space, I think that is more about the qlx driver and not spice on the qemu side. With regard to VNC, as long as VNC lives in the same address space with the guest, it can just follow a dangling pointer and corrupt and crash the guest too like libspice or qcow2 or anything else in that address space could too, or worse silently corrupt guest fs metadata and leave traces of fs corruption that could emerge months or years after the bug was fixed. qlx and paravirt definitely not required for this, VNC can do it too. When you compare Spice to a virtio driver, that implies to me that it does interact directly with the guest. In fact, when you have a driver passing high level commands to Spice, you would think that the status of these commands would be pending state, no? Let's say the guest sends a fill rectangle command and the Spice server sends that to a client. The Spice server needs to know when the client has finished that (maybe not, but let's assume it does) so there is now a pending request that someone has to keep track of. If you do a savevm or a live migration, or the client disconnects, the state of that request has to be saved somewhere (unless you tell the guest that the client has disconnected which is how Xen handles pv device migration). So that's what I'm trying to understand. How far does the guest's visibility go? Is the guest totally ignorant of anything other than QXL? If so, that's good, and I'm very happy about it :-) Regards, Anthony Liguori I would expect it to be ignorant about anything but qlx (what else does it need to know), but I never looked into spice before it was open source so it's not like I'm the right person to ask for those details ;).
Re: [Qemu-devel] Re: Spice project is now open
Andrea Arcangeli wrote: On Sat, Dec 12, 2009 at 05:52:49PM -0600, Anthony Liguori wrote: This is the bit that confuses me. VNC is not a driver. When I say it cannot crash the guest, I mean that if the VNC server makes a mistake, there may be a SEGV in qemu or it may just result in a VNC client seeing corruption. The guest does not see a bad VGA register content though or something like that. VNC is a host driver or backend service or whatever you want to call it. VNC does not have migration state because it has no guest visible state. Again, a guest crash because of qlx interaction is not what I mean. And the reason I wasn't even thinking about this scenario is that the kind of paravirt-driver related guest crash you are talking about, if it can happen, can happen even if spice lib in the qemu side lives in a separate address space. Yes, that's absolutely true. This is why this case of pure guest crash through qlx is not relevant to decide if to have spice lib inside our outside of qemu address space, I think that is more about the qlx driver and not spice on the qemu side. The guest visible state thing has nothing to do with where it lives. Sorry if that's gotten mixed in with this discussion. The reason I care about what interacts directly with the guest is that I'd like to see us move qemu to where there's a very strong separate between guest-visible interactions and then host services to the point where the portions of guest-visible code could be run in a highly secure environment. If all of libspice would have to live in that environment because it interacts with a guest directly, that would get complicated. When you compare Spice to a virtio driver, that implies to me that it does interact directly with the guest. In fact, when you have a driver passing high level commands to Spice, you would think that the status of these commands would be pending state, no? Let's say the guest sends a fill rectangle command and the Spice server sends that to a client. The Spice server needs to know when the client has finished that (maybe not, but let's assume it does) so there is now a pending request that someone has to keep track of. If you do a savevm or a live migration, or the client disconnects, the state of that request has to be saved somewhere (unless you tell the guest that the client has disconnected which is how Xen handles pv device migration). So that's what I'm trying to understand. How far does the guest's visibility go? Is the guest totally ignorant of anything other than QXL? If so, that's good, and I'm very happy about it :-) Regards, Anthony Liguori I would expect it to be ignorant about anything but qlx (what else does it need to know), but I never looked into spice before it was open source so it's not like I'm the right person to ask for those details ;). :-) I'm really interested in those details. Regards, Anthony Liguori
Re: [Qemu-devel] Re: Spice project is now open
On Sat, Dec 12, 2009 at 05:46:08PM -0600, Anthony Liguori wrote: Dor Laor wrote: On 12/12/2009 07:40 PM, Anthony Liguori wrote: If Spice can crash a guest, that indicates to me that Spice is maintaining guest visible state. That is difficult architecturally because if we want to do something like introduce a secure sandbox for running guest visible emulation, libspice would have to be part of that sandbox which would seem to be difficult. The VNC server cannot crash a guest by comparison. That's not accurate: Cannot crash the *guest*. It can crash qemu but it's not guest visible. IOW, the guest never interacts directly with the VNC server. The difference matters when it comes to security sandboxing and live migration. If we'll break spice to components we have the following (and I'm not a spice expert): 1. QXL device/driver pair Is anyone debate we should have it in qemu? We should attach it SDL and vnc backend too anyway. 2. VDI (Virtual Desktop Interface) http://www.spice-space.org/vdi.html FYI, www.spice-space.org is not responding for me. There is a planned outage for a physical relocation of the server that hosts spice-space.org, virt-manager.org, ovirt.org, etc a lot of other sites. It should be back online before Monday if all has gone to plan. Where #3 lives is purely a function of what level of integration it needs with qemu. There may be advantages to having it external to qemu. I actually think we should move the VNC server out of qemu... Dan Berrange and I have been talking about being able to move VNC server into a central process such that all of the VMs can have a single VNC port that can be connected to. This greatly simplifies the firewalling logic that an administrator has to deal with. That's a problem I've already had to deal with for our management tools. We use a private network for management and we bridge the VNC traffic into the customers network so they can see the VGA session. But since that traffic can be a large range of ports and we have to tunnel the traffic through a central server to get into the customer network, it's very difficult to setup without opening up a mess of ports. I think we're currently opening a few thousand just for VNC. Actually my plan was to have a VNC proxy server, that sat between the end user the real VNC in QEMU. Specifically I wanted to allow for a model where the VNC server end users connected to for console servers was on a physically separate host from the VMs. I had a handful of use cases, mostly to deal with an oVirt deployment where console users could be from the internet, rather than an intranet. - Avoiding the need to open up many ports on firewalls - Allow on the fly switching between any VMs the currently authenticated user was authorized to view without opening more connections (avoids needing to re-authenticate for each VM) - Avoid needing to expose virtualization hosts to console users, since console users may be coming in from an untrusted network, or even the internet itself. - Allow seemless migration where proxy server simply re-connects to the VM on new host, without the end user VNC connection ever noticing. For VNC, to make this efficient we just need a shared memory transport that we can use locally. I doubt the added latency will matter as long as we're not copying data. That would preclude running it as an off-node service, but since latency is important that's probably inevitable. In any case there'd be nothing to stop someone adding an off-node proxy in front of that anyway should requirements truely require it. The first point of just getting away from the one-TCP port per VM model is a worthwhile use case all of its own. Of course, Spice is a different thing altogether. I have no idea whether it makes sense for Spice like it would for VNC. But I'd like to understand if the option is available. I believe Spice shares the same needs as VNC in this regard, since when spawning a VM with Spice, each must be given a pair of unique ports (one runs cleartext, one with TLS/SSL). Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Re: [Qemu-devel] Re: Spice project is now open
Paolo Bonzini wrote: On 12/11/2009 10:54 PM, Anthony Liguori wrote: The point is, there isn't a draw a rectangle primitive in X. There also isn't a draw some text using this font in X.[1] Not necessarily, the X server can support the render extension which allows compositing operations on an X pixmap. Firefox uses that extensively, for example to render tiled backgrounds (though probably GTK user interface elements can do so less successfully). Yes, but this is just a single application. The point is that these things are not as widely standardized on X as they are on Windows. Regards, Anthony Liguori Paolo
