Re: [vdsm] API Documentation & Since tag
- Original Message - > From: "Adam Litke" > To: "Saggi Mizrahi" > Cc: vdsm-devel@lists.fedorahosted.org, "Vinzenz Feenstra" > > Sent: Tuesday, January 15, 2013 9:27:31 AM > Subject: Re: [vdsm] API Documentation & Since tag > > On Mon, Jan 14, 2013 at 05:45:45PM -0500, Saggi Mizrahi wrote: > > > > > > - Original Message - > > > From: "Adam Litke" > > > To: "Saggi Mizrahi" > > > Cc: vdsm-devel@lists.fedorahosted.org, "Vinzenz Feenstra" > > > > > > Sent: Monday, January 14, 2013 5:21:41 PM > > > Subject: Re: [vdsm] API Documentation & Since tag > > > > > > On Mon, Jan 14, 2013 at 12:37:57PM -0500, Saggi Mizrahi wrote: > > > > > > > > > > > > - Original Message - > > > > > From: "Adam Litke" > > > > > To: "Vinzenz Feenstra" > > > > > Cc: vdsm-devel@lists.fedorahosted.org > > > > > Sent: Friday, January 11, 2013 9:03:19 AM > > > > > Subject: Re: [vdsm] API Documentation & Since tag > > > > > > > > > > On Fri, Jan 11, 2013 at 10:19:45AM +0100, Vinzenz Feenstra > > > > > wrote: > > > > > > Hi everyone, > > > > > > > > > > > > We are currently documenting the API in vdsmapi-schema.json > > > > > > I noticed that we have there documented when a certain > > > > > > element > > > > > > newly > > > > > > is introduced using the 'Since' tag. > > > > > > However I also noticed that we are not documenting when a > > > > > > field > > > > > > was > > > > > > newly added, nor do we update the 'since' tag. > > > > > > > > > > > > We should start documenting in what version we've > > > > > > introduced a > > > > > > field. > > > > > > A suggestion by saggi was to add to the comment for > > > > > > example: > > > > > > @since: 4.10.3 > > > > > > > > > > > > What is your point of view on this? > > > > > > > > > > I do think it's a good idea to add this information. How > > > > > about > > > > > supporting > > > > > multiple Since lines in the comment like the following made > > > > > up > > > > > example: > > > > > > > > > > ## > > > > > # @FenceNodePowerStatus: > > > > > # > > > > > # Indicates the power state of a remote host. > > > > > # > > > > > # @on:The remote host is powered on > > > > > # > > > > > # @off: The remote host is powered off > > > > > # > > > > > # @unknown: The power status is not known > > > > > # > > > > > # @sentient: The host is alive and powered by its own > > > > > metabolism > > > > > # > > > > > # Since: 4.10.0 - @FenceNodePowerStatus > > > > > # Since: 10.2.0 - @sentient > > > > > ## > > > > I don't like the fact that both lines don't point to the same > > > > type > > > > of token. > > > > I also don't like that it's a repeat of the type names and > > > > field > > > > names. > > > > > > > > I prefer Vinzenz original suggestion (on IRC) of moving the > > > > "Since" > > > > token up and then > > > > have it be a state. It also makes discerning what entities you > > > > can > > > > use up to a > > > > certain version easier if you make sure to keep them sorted. > > > > > > > > We can do this because the order of the fields and availability > > > > is > > > > undetermined (unlike real structs). > > > > > > That is not correct. These structures are parsed into an > > > OrderedDict > > > and the > > > ordering is important (especially for languages like C which > > > might > > > use real > > > structs). > > The "wire" format, json, ignores the ordering, further more, for > > languages like C we can't use actual structs because then we have > > to bump a major version every time we add a field as the > > sizeof(struct Foo) changed > > > > > > > > > > > ## > > > > # @FenceNodePowerStatus: > > > > # > > > > # Indicates the power state of a remote host. > > > > # > > > > # Since: 4.10.0 > > > > # > > > > # @on:The remote host is powered on > > > > # > > > > # @off: The remote host is powered off > > > > # > > > > # @unknown: The power status is not known > > > > # > > > > # Since: 10.2.0 > > > > # > > > > # @sentient: The host is alive and powered by its own > > > > metabolism > > > > # > > > > ## > > > > > > > > The problem though is that it makes since a property of the > > > > fields > > > > and not of > > > > the struct. This isn't that much of a problem as we can assume > > > > the > > > > earliest > > > > version is the time when the struct was introduced. > > > > > > I don't like this any better than my suggestion. Aside from the > > > fact > > > that field > > > ordering is important (in the data structure itself), this > > > spreads > > > the since > > > information throughout the comment rather than concentrating it > > > in a > > > single > > > place. > > > > Well, thinking about it, I don't understand why structs need to > > have a > > "Since" property anyway. Only verbs should have it. Structs are > > available (by inference) since the earliest call that produces > > them. > > > > All fields in a struct are optional anyway. Old versions wouldn't > > try > > and access them, new clients should alway
Re: [vdsm] RFC: New Storage API
- Original Message -
> From: "Ayal Baron"
> To: "Saggi Mizrahi"
> Cc: "engine-devel" , "VDSM Project Development"
> , "Deepak
> C Shetty"
> Sent: Monday, January 14, 2013 6:23:32 PM
> Subject: Re: [vdsm] RFC: New Storage API
>
>
>
> - Original Message -
> >
> >
> > - Original Message -
> > > From: "Ayal Baron"
> > > To: "Saggi Mizrahi"
> > > Cc: "engine-devel" , "VDSM Project
> > > Development" , "Deepak
> > > C Shetty"
> > > Sent: Monday, January 14, 2013 4:56:05 PM
> > > Subject: Re: [vdsm] RFC: New Storage API
> > >
> > >
> > >
> > > - Original Message -
> > > >
> > > >
> > > > - Original Message -
> > > > > From: "Deepak C Shetty"
> > > > > To: "Saggi Mizrahi"
> > > > > Cc: "Shu Ming" , "engine-devel"
> > > > > , "VDSM Project Development"
> > > > > , "Deepak C Shetty"
> > > > >
> > > > > Sent: Sunday, December 16, 2012 11:40:01 PM
> > > > > Subject: Re: [vdsm] RFC: New Storage API
> > > > >
> > > > > On 12/08/2012 01:23 AM, Saggi Mizrahi wrote:
> > > > > >
> > > > > > - Original Message -
> > > > > >> From: "Deepak C Shetty"
> > > > > >> To: "Saggi Mizrahi"
> > > > > >> Cc: "Shu Ming" ,
> > > > > >> "engine-devel"
> > > > > >> , "VDSM Project Development"
> > > > > >> , "Deepak C Shetty"
> > > > > >>
> > > > > >> Sent: Friday, December 7, 2012 12:23:15 AM
> > > > > >> Subject: Re: [vdsm] RFC: New Storage API
> > > > > >>
> > > > > >> On 12/06/2012 10:22 PM, Saggi Mizrahi wrote:
> > > > > >>> - Original Message -
> > > > > From: "Shu Ming"
> > > > > To: "Saggi Mizrahi"
> > > > > Cc: "VDSM Project Development"
> > > > > , "engine-devel"
> > > > >
> > > > > Sent: Thursday, December 6, 2012 11:02:02 AM
> > > > > Subject: Re: [vdsm] RFC: New Storage API
> > > > >
> > > > > Saggi,
> > > > >
> > > > > Thanks for sharing your thought and I get some comments
> > > > > below.
> > > > >
> > > > >
> > > > > Saggi Mizrahi:
> > > > > > I've been throwing a lot of bits out about the new
> > > > > > storage
> > > > > > API
> > > > > > and
> > > > > > I think it's time to talk a bit.
> > > > > > I will purposefully try and keep implementation details
> > > > > > away
> > > > > > and
> > > > > > concentrate about how the API looks and how you use it.
> > > > > >
> > > > > > First major change is in terminology, there is no long
> > > > > > a
> > > > > > storage
> > > > > > domain but a storage repository.
> > > > > > This change is done because so many things are already
> > > > > > called
> > > > > > domain in the system and this will make things less
> > > > > > confusing
> > > > > > for
> > > > > > new-commers with a libvirt background.
> > > > > >
> > > > > > One other changes is that repositories no longer have a
> > > > > > UUID.
> > > > > > The UUID was only used in the pool members manifest and
> > > > > > is
> > > > > > no
> > > > > > longer needed.
> > > > > >
> > > > > >
> > > > > > connectStorageRepository(repoId, repoFormat,
> > > > > > connectionParameters={}):
> > > > > > repoId - is a transient name that will be used to refer
> > > > > > to
> > > > > > the
> > > > > > connected domain, it is not persisted and doesn't have
> > > > > > to
> > > > > > be
> > > > > > the
> > > > > > same across the cluster.
> > > > > > repoFormat - Similar to what used to be type (eg.
> > > > > > localfs-1.0,
> > > > > > nfs-3.4, clvm-1.2).
> > > > > > connectionParameters - This is format specific and will
> > > > > > used
> > > > > > to
> > > > > > tell VDSM how to connect to the repo.
> > > > > Where does repoID come from? I think repoID doesn't
> > > > > exist
> > > > > before
> > > > > connectStorageRepository() return. Isn't repoID a
> > > > > return
> > > > > value
> > > > > of
> > > > > connectStorageRepository()?
> > > > > >>> No, repoIDs are no longer part of the domain, they are
> > > > > >>> just
> > > > > >>> a
> > > > > >>> transient handle.
> > > > > >>> The user can put whatever it wants there as long as it
> > > > > >>> isn't
> > > > > >>> already taken by another currently connected domain.
> > > > > >> So what happens when user mistakenly gives a repoID that
> > > > > >> is
> > > > > >> in
> > > > > >> use
> > > > > >> before.. there should be something in the return value
> > > > > >> that
> > > > > >> specifies
> > > > > >> the error and/or reason for error so that user can try
> > > > > >> with
> > > > > >> a
> > > > > >> new/diff
> > > > > >> repoID ?
> > > > > > Asi I said, connect fails if the repoId is in use ATM.
> > > > > > disconnectStorageRepository(self, repoId)
> > > > > >
> > > > > >
> > > > > > In the new API there are only images, some images are
> > > > > > mutable
> > > > > > and
> > >
Re: [vdsm] remote serial console via HTTP streaming handler
Good to see my suggestion didn't fall on deaf ears. - Original Message - > From: "Zhou Zheng Sheng" > To: "Saggi Mizrahi" > Cc: "VDSM Project Development" , "Adam > Litke" , "Ayal Baron" > , "Barak Azulay" , "Dan Kenigsberg" > > Sent: Tuesday, January 15, 2013 4:30:03 AM > Subject: Re: remote serial console via HTTP streaming handler > > > on 01/08/2013 04:10, Saggi Mizrahi wrote: > > The solution is somewhat elegant (and only ~150 LOC). > > That being said I still have some 2 major problems with it: > > The simpler one is that it uses HTTP in a very non-standard manner, > > this > > can be easily solved by using websockets[2]. This is very close > > to what the patch already does and will make it follow some sort of > > a > > standard. This will also enable console on the Web UI to expose > > this on > > newer browsers. > Using WebSocket is a good idea. I have a look at its standard > (http://tools.ietf.org/html/rfc6455). The framing and the security > model > is not trivial to implement (compared to that existing patch which > enables HTTP to forward PTY octet stream in full duplex). Luckily > there > are some open-source WebSocket implementations. > > The second and the real reason I didn't put it just as a comment on > > the > > patch is that that using HTTP and POST %PATH to have only one > > listening > > socket for all VMs is completely different from the way we do VNC > > or SPICE. > > This means it kind of bypasses ticketing and any other mechanism we > > want > > to put on VM interfaces. > I think HTTP digest authentication may be implemented in the current > PTY > forwarding patch to enable ticketing. > > > The thing is, I really like it. I was suggesting that we extend > > this idiom > > to use for SPICE and VNC and tunneling it through a single > > http\websocket > > listener. So instead of making this work with the current methods > > make this > > the way to go. > > > > Using headers like: > > GET /VM//control HTTP/1.1 > > Host: server.example.com > > Upgrade: websocket > > Ticket: > > Connection: Upgrade > > Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== > > Sec-WebSocket-Protocol: [pty, vnc, spice] > > Sec-WebSocket-Version: 13 > > Origin:http://example.com > In the Spice official site, I see a demo project spice-html5 uses a > WebSocket-Spice gateway to get the data. The Spice is tunneled in > WebSocket between the client and the gateway. This is good for > javascript running in browsers. If VDSM support tunneling the PTY, > VNC > and Spice in WebSocket, writing a viewers in browsers maybe easier. > > A WebSocket proxy can also be implemented to support migration with > PTY. > The PTY data stream is VDSM<=>proxy<=>client. When migrating, VDSM > sends > this event to proxy via AMQP, then shuts down the current WebSocket > connection. The proxy can keep the connection with the client. After > migration, another VDSM sends this event to proxy via AMQP, then the > proxy establish the WebSocket connection with VDSM and continue the > forwarding. > > We can also connect two guests' serial port by forwarding the data > stream via this proxy back and forth with support for migration as > explained above. Furthermore, the proxy can exposes the data stream > in > various plug-in protocols such as SOCKS, HTTP, SSH, telnet to various > client. For example the proxy provide SOCKS support, then we can use > socat as a SOCKS client to connect to guest serial port and pipe the > data to FD 0 and 1 to a process running in the host. Also, I don't think it's such a problem to have the client change "servers" usually even if websockets are invovled. It just means that client needs to be aware of the possibility of an extra layer. > > -- > Thanks and best regards! > > Zhou Zheng Sheng / 周征晟 > E-mail:zhshz...@linux.vnet.ibm.com > Telephone: 86-10-82454397 > > ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] libvirt interface usage improvements, #1
- Original Message - > From: "Daniel P. Berrange" > To: "Peter V. Saveliev" > Cc: "VDSM Project Development" > Sent: Tuesday, January 15, 2013 5:35:11 PM > Subject: Re: [vdsm] libvirt interface usage improvements, #1 > > On Tue, Jan 15, 2013 at 05:08:59PM +0100, Peter V. Saveliev wrote: > > … > > > > Hello all. > > > > I'm working on improving libvirt usage in VDSM. Rationale is that > > libvirt driver has global lock, that holds us in any operation on > > many VMs simultaneously. Several small patches are prepared, so I'm > > starting to commit them. > > FYI the global lock will be dead in either the next libvirt release, > or the one after. So I wouldn't jump through too many hoops in VDSM > for this IMHO. Good news! Keep up the good work ;-) > > > The first one [1] removes UUIDString check in VM startup. It was > > used to test local libvirt for the bug 603494 [2], which is closed > > so long time ago, so there is no need to support this case, fixed > > already all across the distributives, including RHEL 6.x. > > > > I wouldn't care, but in mass VM startup (dozens and hundreds of > > VMs) > > each extra call costs. So thanks for review/merge. > > The UUIDString() method executes purely client side so does not > involve any libvirt locks. > > Daniel > -- > |: http://berrange.com -o- > | http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- > |http://virt-manager.org :| > |: http://autobuild.org -o- > |http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- > | http://live.gnome.org/gtk-vnc :| > ___ > vdsm-devel mailing list > vdsm-devel@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] libvirt interface usage improvements, #1
On Tue, Jan 15, 2013 at 05:08:59PM +0100, Peter V. Saveliev wrote: > … > > Hello all. > > I'm working on improving libvirt usage in VDSM. Rationale is that > libvirt driver has global lock, that holds us in any operation on > many VMs simultaneously. Several small patches are prepared, so I'm > starting to commit them. FYI the global lock will be dead in either the next libvirt release, or the one after. So I wouldn't jump through too many hoops in VDSM for this IMHO. > The first one [1] removes UUIDString check in VM startup. It was > used to test local libvirt for the bug 603494 [2], which is closed > so long time ago, so there is no need to support this case, fixed > already all across the distributives, including RHEL 6.x. > > I wouldn't care, but in mass VM startup (dozens and hundreds of VMs) > each extra call costs. So thanks for review/merge. The UUIDString() method executes purely client side so does not involve any libvirt locks. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] libvirt interface usage improvements, #1
… Hello all. I'm working on improving libvirt usage in VDSM. Rationale is that libvirt driver has global lock, that holds us in any operation on many VMs simultaneously. Several small patches are prepared, so I'm starting to commit them. The first one [1] removes UUIDString check in VM startup. It was used to test local libvirt for the bug 603494 [2], which is closed so long time ago, so there is no need to support this case, fixed already all across the distributives, including RHEL 6.x. I wouldn't care, but in mass VM startup (dozens and hundreds of VMs) each extra call costs. So thanks for review/merge. [1] — http://gerrit.ovirt.org/#/c/11054/ [2] — https://bugzilla.redhat.com/show_bug.cgi?id=603494 -- Peter V. Saveliev ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] API Documentation & Since tag
On Mon, Jan 14, 2013 at 05:45:45PM -0500, Saggi Mizrahi wrote: > > > - Original Message - > > From: "Adam Litke" > > To: "Saggi Mizrahi" > > Cc: vdsm-devel@lists.fedorahosted.org, "Vinzenz Feenstra" > > > > Sent: Monday, January 14, 2013 5:21:41 PM > > Subject: Re: [vdsm] API Documentation & Since tag > > > > On Mon, Jan 14, 2013 at 12:37:57PM -0500, Saggi Mizrahi wrote: > > > > > > > > > - Original Message - > > > > From: "Adam Litke" > > > > To: "Vinzenz Feenstra" > > > > Cc: vdsm-devel@lists.fedorahosted.org > > > > Sent: Friday, January 11, 2013 9:03:19 AM > > > > Subject: Re: [vdsm] API Documentation & Since tag > > > > > > > > On Fri, Jan 11, 2013 at 10:19:45AM +0100, Vinzenz Feenstra wrote: > > > > > Hi everyone, > > > > > > > > > > We are currently documenting the API in vdsmapi-schema.json > > > > > I noticed that we have there documented when a certain element > > > > > newly > > > > > is introduced using the 'Since' tag. > > > > > However I also noticed that we are not documenting when a field > > > > > was > > > > > newly added, nor do we update the 'since' tag. > > > > > > > > > > We should start documenting in what version we've introduced a > > > > > field. > > > > > A suggestion by saggi was to add to the comment for example: > > > > > @since: 4.10.3 > > > > > > > > > > What is your point of view on this? > > > > > > > > I do think it's a good idea to add this information. How about > > > > supporting > > > > multiple Since lines in the comment like the following made up > > > > example: > > > > > > > > ## > > > > # @FenceNodePowerStatus: > > > > # > > > > # Indicates the power state of a remote host. > > > > # > > > > # @on:The remote host is powered on > > > > # > > > > # @off: The remote host is powered off > > > > # > > > > # @unknown: The power status is not known > > > > # > > > > # @sentient: The host is alive and powered by its own metabolism > > > > # > > > > # Since: 4.10.0 - @FenceNodePowerStatus > > > > # Since: 10.2.0 - @sentient > > > > ## > > > I don't like the fact that both lines don't point to the same type > > > of token. > > > I also don't like that it's a repeat of the type names and field > > > names. > > > > > > I prefer Vinzenz original suggestion (on IRC) of moving the "Since" > > > token up and then > > > have it be a state. It also makes discerning what entities you can > > > use up to a > > > certain version easier if you make sure to keep them sorted. > > > > > > We can do this because the order of the fields and availability is > > > undetermined (unlike real structs). > > > > That is not correct. These structures are parsed into an OrderedDict > > and the > > ordering is important (especially for languages like C which might > > use real > > structs). > The "wire" format, json, ignores the ordering, further more, for > languages like C we can't use actual structs because then we have > to bump a major version every time we add a field as the > sizeof(struct Foo) changed > > > > > > > > ## > > > # @FenceNodePowerStatus: > > > # > > > # Indicates the power state of a remote host. > > > # > > > # Since: 4.10.0 > > > # > > > # @on:The remote host is powered on > > > # > > > # @off: The remote host is powered off > > > # > > > # @unknown: The power status is not known > > > # > > > # Since: 10.2.0 > > > # > > > # @sentient: The host is alive and powered by its own metabolism > > > # > > > ## > > > > > > The problem though is that it makes since a property of the fields > > > and not of > > > the struct. This isn't that much of a problem as we can assume the > > > earliest > > > version is the time when the struct was introduced. > > > > I don't like this any better than my suggestion. Aside from the fact > > that field > > ordering is important (in the data structure itself), this spreads > > the since > > information throughout the comment rather than concentrating it in a > > single > > place. > > Well, thinking about it, I don't understand why structs need to have a > "Since" property anyway. Only verbs should have it. Structs are > available (by inference) since the earliest call that produces them. > > All fields in a struct are optional anyway. Old versions wouldn't try > and access them, new clients should always assume these fields may > not be returned anyway. All _newly_added_ fields must be optional. Fields that are part of the original definition of the type can be required fields. This reminds me that we will need to audit the schema for fields that can be made optional. For example, when creating Vm*Device objects, the VmDeviceAddress member can be omitted. -- Adam Litke IBM Linux Technology Center ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] Q on git-review error
Hi All, I got this error, while trying to push a topic branch..but in the end it looks like it did push the GLUSTERSD_DOMAIN patch ( which had a minor change ). The other 2 patches didn't have any change. Finally when i look up in gerrit, it shows GLUSTERSD_DOMAIn patch fine, but the link of that with the other 2 patches seems to have broken git-review -t gluster_domain_support You have more than one commit that you are about to submit. The outstanding commits are: 29f2048 (HEAD, dpk-gluster-support) tests/functional: Add GlusterSD functional test 3cc6fca tests/functional: Use deleteVolume instead of deleteImage 6d71286 Support for GLUSTERFS_DOMAIN Is this really what you meant to do? Type 'yes' to confirm: yes remote: Resolving deltas: 100% (20/20) remote: Processing changes: done remote: error: internal error while processing changes <<< throwing some error To ssh://dpkshe...@gerrit.ovirt.org:29418/vdsm.git * [new branch] HEAD -> refs/publish/master/gluster_domain_support it did push tho' ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] remote serial console via HTTP streaming handler
on 01/08/2013 04:10, Saggi Mizrahi wrote: The solution is somewhat elegant (and only ~150 LOC). That being said I still have some 2 major problems with it: The simpler one is that it uses HTTP in a very non-standard manner, this can be easily solved by using websockets[2]. This is very close to what the patch already does and will make it follow some sort of a standard. This will also enable console on the Web UI to expose this on newer browsers. Using WebSocket is a good idea. I have a look at its standard (http://tools.ietf.org/html/rfc6455). The framing and the security model is not trivial to implement (compared to that existing patch which enables HTTP to forward PTY octet stream in full duplex). Luckily there are some open-source WebSocket implementations. The second and the real reason I didn't put it just as a comment on the patch is that that using HTTP and POST %PATH to have only one listening socket for all VMs is completely different from the way we do VNC or SPICE. This means it kind of bypasses ticketing and any other mechanism we want to put on VM interfaces. I think HTTP digest authentication may be implemented in the current PTY forwarding patch to enable ticketing. The thing is, I really like it. I was suggesting that we extend this idiom to use for SPICE and VNC and tunneling it through a single http\websocket listener. So instead of making this work with the current methods make this the way to go. Using headers like: GET /VM//control HTTP/1.1 Host: server.example.com Upgrade: websocket Ticket: Connection: Upgrade Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== Sec-WebSocket-Protocol: [pty, vnc, spice] Sec-WebSocket-Version: 13 Origin:http://example.com In the Spice official site, I see a demo project spice-html5 uses a WebSocket-Spice gateway to get the data. The Spice is tunneled in WebSocket between the client and the gateway. This is good for javascript running in browsers. If VDSM support tunneling the PTY, VNC and Spice in WebSocket, writing a viewers in browsers maybe easier. A WebSocket proxy can also be implemented to support migration with PTY. The PTY data stream is VDSM<=>proxy<=>client. When migrating, VDSM sends this event to proxy via AMQP, then shuts down the current WebSocket connection. The proxy can keep the connection with the client. After migration, another VDSM sends this event to proxy via AMQP, then the proxy establish the WebSocket connection with VDSM and continue the forwarding. We can also connect two guests' serial port by forwarding the data stream via this proxy back and forth with support for migration as explained above. Furthermore, the proxy can exposes the data stream in various plug-in protocols such as SOCKS, HTTP, SSH, telnet to various client. For example the proxy provide SOCKS support, then we can use socat as a SOCKS client to connect to guest serial port and pipe the data to FD 0 and 1 to a process running in the host. -- Thanks and best regards! Zhou Zheng Sheng / 周征晟 E-mail:zhshz...@linux.vnet.ibm.com Telephone: 86-10-82454397 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
