On Fri, Mar 28, 2014 at 08:06:17AM -0400, Frantisek Kobzik wrote:
> Dear VDSM devels,
>
> I've been working on refactoring graphics devices in engine and VDSM for some
> time now and I'd like know your opinion of that.
>
> The aim of this refactoring is to model graphics framebuffer (SPICE, VNC) as
> device in the engine and VDSM. This which is quite natural since libvirt
> treats
> graphics as a device and we have some kind of devices infrastructure in both
> projects. Another advantage (and actually the main reason for refactoring) is
> simplified support for multiple graphics framebuffers on a single vm.
>
> Currently, passing information about graphics from engine to VDSM is done via
> 'display' param in conf. In the other direction VDSM informs the engine about
> graphics parameters ('displayPort', 'displaySecurePort', 'displayIp' and
> 'displayNetwork') in conf as well.
>
> What I'd like to achieve is to encapsulate all this information in specParams
> of the new graphics device and use specParams as a place for transfering data
> about graphics device between engine and vdsm. What do you think?
>
> the draft patch is here:
> http://gerrit.ovirt.org/#/c/23555/ (it's currently marked with '-1' but it
> puts
> some light on what the solution looks like so feel free to take a look).
Thanks for the heads up. I'd appreciate if you could split this patch to
smaller ones, and define well-named functions as much as possible. It's
not your fault, but vm.py is in such a shape that adding more complexity
into it should be done with great care.
So even if the patches are interdependent, the review process would be
simpler.
Another high-level note that I have is that you should care for
reporting displayPort on the vm level only for those Engines that care
for that, so if you have multiple graphics devices - you should not.
Regards,
Dan.
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
