On Nov 26, 2013, at 15:57 , Frantisek Kobzik <fkob...@redhat.com> wrote:
> Hi guys, > > I created a wiki page with the feature: > http://www.ovirt.org/Features/Multiple_Consoles > > It contains information about possible redesign of Engine<->VDSM > communication. > I'd appreciate if you take a look at it since it's not trivial change. > > I welcome opinions from both engine and vdsm devels. I think we indeed have to split video device from graphics device and treat it separately… Thanks, michal > > Cheers, > F. > > ----- Original Message ----- > From: "Frantisek Kobzik" <fkob...@redhat.com> > To: vdsm-de...@lists.fedorahosted.org > Sent: Monday, November 25, 2013 2:23:59 PM > Subject: Re: [vdsm] Multiple graphics framebuffers - VDSM support > > Hi, > > it's been some time since the original mail, so I'm sending updated > information. > > > ----- Original Message ----- > From: "Frantisek Kobzik" <fkob...@redhat.com> > To: vdsm-de...@lists.fedorahosted.org > Sent: Thursday, November 7, 2013 11:47:46 AM > Subject: [vdsm] Multiple graphics framebuffers - VDSM support > > Dear VDSM developers, > > I'm working on a patch that allows running a VM with multiple graphics > framebuffers. This is handy when you want to run a VM with both SPICE and > VNC. It's a 3.4 feature and it will certainly need a change in vdsm. > Here is a list of changes in VDSM that are needed for this funcionality: > a, Sending graphics/video (engine->vdsm) > - currently we send two things: > 1, "display" value (qxl/vnc [wat]) > - vdsm uses this for determining if the graphics server is SPICE or VNC > - this attribute is not really correct - it mixes up semantics of graphic > framebuffer and videocard together. I believe this attribute should only > contain information about the graphics ('spice', 'vnc' or 'spice,vnc' if > you want both). if this the case, do you think we should rename the > attribute > to, let's say, 'graphics'? Is it even possible with regard to backward > compatibility? or should I reuse 'display' attribute? > 2, video device (json representation of the video card) - this is correct > > b, Reporting graphics ports (vdsm->engine) > - currently we report 2 graphic ports ('displayPort' and 'secureDisplayPort') > - if we want multiple framebuffers, we must report more ports (for VNC and > SPICE together that would mean 3 ports (2 for spice, one for vnc). > - there are two possible solutions for this: > 1, ditch 'displayPort' and 'secureDisplayPort' and add new 'spicePort', > 'spiceSecurePort', 'vncPort' fields or some kind of two level dict: > { protocol -> secured/unsecured -> portNumber } > 2, keep 'displayPort' and 'secureDisplayPort' and introduce new > 'additionalDisplayPort' > This would be friendlier to backward compatibility, but it's extremely > ugly because of unclear semantics of the fields (in case of SPICE+VNC > 'displayPort' and 'secureDisplayPort' would be related to SPICE, > 'additionalDisplayPort' would be the VNC port. In case of VNC only, the > 'displayPort' would be suddendly VNC port... ewww). > > I'd be very happy if you share your opinion about these changes. > > Cheers, > Franta. > _______________________________________________ > vdsm-devel mailing list > vdsm-de...@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > _______________________________________________ > vdsm-devel mailing list > vdsm-de...@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
