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.

>  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 
In order to keep backwards compatibility after rename, engine would have to
send different command to newer/older VDSMs as older VDSM has no code to understand
different keyword - I'd say keep the name "display".

>  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). 
Same difficulty as previous case but on engine side: unless older engine can
process new keywords, our best and only backwards compatible choice is adding
a new field.

Also what won't remain unaffected is migration: migrating VM with multiple
framebuffers to older VDSM will afaik require patching the config causing
VM to only run with one framebuffer, possibly losing the information that
another was attached (in case of another migration to new VDSM).

Martin

Hi Martin, thanks for feedback (details below).

I'll try to bump this thread with new information later today.

----- Original Message -----
From: "Martin Polednik" <mpoledni(a)redhat.com&gt;
To: "Frantisek Kobzik" <fkobzik(a)redhat.com&gt;
Cc: vdsm-devel(a)lists.fedorahosted.org
Sent: Friday, November 8, 2013 5:48:02 PM
Subject: Re: [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 
>  In order to keep backwards compatibility after rename, engine would
> have to 
send different command to newer/older VDSMs as older VDSM has no code to
understand
different keyword - I'd say keep the name "display".

Yes, in this case engine would make that decision based on cluster compatibility version.

>  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). 
>  Same difficulty as previous case but on engine side: unless older
> engine can 
process new keywords, our best and only backwards compatible choice is
adding
a new field.

I've got the same opinion.

>  Also what won't remain unaffected is migration: migrating VM with
> multiple 
framebuffers to older VDSM will afaik require patching the config causing
VM to only run with one framebuffer, possibly losing the information that
another was attached (in case of another migration to new VDSM).

Migration shouldn't be the issue IMHO. Migration of a vm with multiple <graphics
.../> to old vdsm shouldn't happen. There some situation  however that must be
taken into account (like 'new' host existing within cluster with 3.3 compatibility
version etc.).

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.

Cheers,
F.

----- Original Message -----
From: "Frantisek Kobzik" <fkobzik(a)redhat.com&gt;
To: vdsm-devel(a)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" <fkobzik(a)redhat.com&gt;
To: vdsm-devel(a)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-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

On Nov 26, 2013, at 15:57 , Frantisek Kobzik <fkobzik(a)redhat.com&gt; 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" <fkobzik(a)redhat.com&gt;
>  To: vdsm-devel(a)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" <fkobzik(a)redhat.com&gt;
>  To: vdsm-devel(a)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-devel(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>  _______________________________________________
>  vdsm-devel mailing list
>  vdsm-devel(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel