Re: [vdsm] new API verb: getVersionInfo()
On 10/18/2012 10:11 PM, Saggi Mizrahi wrote: I don't see how pyinotify is even related to storage stats. Well I am not sure where I would have mentioned storage statistics. It doesn't work with NFS and is a bit flaky when it comes to VFSs like proc or dev. Also it doesn't check liveness or latency so the events don't really give us anything useful. It's not like that pyinotify is the holy grail for all purposes. I was talking about caching the package (rpm/dpkg) changes and have pyinotify track this for cache invalidation. After that I wrote that I really would like to cache everything. The data is being taken from cache. I assume there is a prepare call there that makes everything slower. What is 'everything'? You might have a slightly slower start up of VDSM however a faster response on getCaps. once everything is going to be cached. I am not sure where this relates to 'make everything slower'. This will only be fixed with new style domains that don't have a built in sdUUID. That is a particular problem then. And I have said that I will send it to the list before, so we can speak about the pro/contras in the proposal to fix it. - Original Message - From: Vinzenz Feenstra vfeen...@redhat.com To: Itamar Heim ih...@redhat.com Cc: Saggi Mizrahi smizr...@redhat.com, Michal Skrivanek mskri...@redhat.com, vdsm-devel@lists.fedorahosted.org Sent: Thursday, October 18, 2012 3:15:47 PM Subject: Re: [vdsm] new API verb: getVersionInfo() On 10/18/2012 08:34 PM, Itamar Heim wrote: On 10/18/2012 06:03 PM, Saggi Mizrahi wrote: currently getVdsCaps() does a lot of unrelated things most of them have no relation to capabilites. This was done because of HTTP overhead. Instead of calling multiple commands we will call one that does everything. I agree with the suggestion that getVdsCaps() will actually return the capabilities. Capabilities being: - storage core version supported domain formats - VM core version and supported host capabilites. - network core and capabilities. - etc... These all should be mostly static and set at boot. As to the query API. I personally dislike the idea of a bag API. Now that we are moving away from HTTP, call overhead is no longer an issue so we can have multiple verbs and call them sequentially. In actuality we already do. Internally getVdsCaps() just aggregates other APIs. This makes return values of the method easier to handle and makes changing the results of an API call not affect users that don't care about that change. This also has better performance as storage APIs tend to slow the response and sending multiple commands would mean that you can get the Network stats even though the storage server is down. i thought getVdsCaps return the storage results from cache, which is refreshed by another thread, to make sure getVdsCaps has no latency. Well this is what it should do but it still doesn't do it. At least from what I have seen so far. I am currently working on a PoC implementation for caching packages and having so pyinotify based trigger for refreshing the cache. I plan to really cache everything and we'll have a background thread running for updating the cached data on changes. I will be sending the proposed solution for it to the list. So we can discuss it into more details. -- Regards, Vinzenz Feenstra Senior Software Engineer IRC: vfeenstr or evilissimo -- Regards, Vinzenz Feenstra Senior Software Engineer IRC: vfeenstr or evilissimo ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Spice-devel] [RFC]about the implement of text-based console
Itamar Heim píše v Čt 18. 10. 2012 v 20:32 +0200: On 10/18/2012 12:13 PM, Alon Levy wrote: On 10/16/2012 12:18 AM, David Jaša wrote: [snip] Extending spice to provide just serial console remoting actually seems the easiest way to provide remote text-only console because most of the code path is already mature (used for client to guest agent communication) and e.g. spicy to just provide a device where e.g. screen could connect or just provide the console itself. CCing spice-devel would it allow users to script with/over it like they can with ssh? If I understand correctly the idea is to add another channel for spice that would connect to a char device in qemu that in turn connects to a serial port. The result is a spice client that can display and interact, but not a scripting extension. We could also create a unix domain socket to expose this connection on the client, and the client could then use that for scripting (but this will be instead of displaying, since you can't multiplex the console in a meaningful way - unless you run screen/tmux over it maybe): remote-viewer --spice-console-unix-domain-socket /tmp/spice.uds (This option assumes we want a single console channel - if we have multiple we will need to name them too) Anyone will be able to script it using for instance: socat UNIX-CONNECT:/tmp/spice.uds SYSTEM:echo hello world We could also turn it into a pty (socat can do that). i think using spice this way may be a very good solution, to proxy a serial console. only caveat is it requires client to install spice, vs. just using ssh. Jarda (To:) actually asked me if this feature (serial device pass through without any graphics) was feasible for purposes of connecting remotely to serial console. Jarda, would the solution outlined by Alon be good for you? Alon, one problem comes to my mind though: it would need either second spice server, or multi-client support (limited one would be enough to have simultaneously one graphics user and one serial device user). Do you think it is possible to implement such things without much effort? If we constrain it to one graphics only (no serial connection, i.e. same channels as today) and one serial only (i.e. main channel - since we have to have that, and the new serial console channel), I think it should not pose any of the problems keeping usable multiple client mode from being implemented, i.e. handling different speed clients. David -- David Jaša, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
