[Ovirt-devel] Re: [PATCH server] allow admin to setup iptables port forwarding on server for a vm's vnc port

[Mohammed Morsi]

Daniel P. Berrange wrote:
> On Mon, Feb 02, 2009 at 11:00:30PM +0000, David Lutterkort wrote:
>   
>> On Mon, 2009-02-02 at 17:48 -0500, Mohammed Morsi wrote:
>>     
>>> David Lutterkort wrote:
>>>       
>>>> On Wed, 2009-01-28 at 20:16 -0500, Mohammed Morsi wrote:
>>>>
>>>> To address the race condition, the simplest solution is to take an
>>>> exclusive table lock on the vms table (before listing the assigned vnc
>>>> ports !) and hold that until the vm is saved in the DB, i.e. the end of
>>>> the current transaction.
>>>>
>>>>   
>>>>         
>>> This is not done as I'm a little concerned about locking the table (what
>>> if the user doesn't submit the form and walks away, will it stay
>>> locked?).
>>>       
>> I must have misunderstood the logic: I thought the port-assignment logic
>> was happening as part of saving the VM, not when the form is presented
>> to the user.
>>     
>
> I rather think both options are wrong. Automatic port assignment should
> be just done when starting a VM, so you don't have to reserve a tonne
> of ports for inactive VMs.
>
>   
This makes sense, save for the manual port assignment scenario as
discussed below. I could add another flag (or change the boolean
forward_vnc field to an int) in the db and vm form to store whether or
not to defer autoassignment to vm startup, in order to handle both
scenarios.


>>>  I changed the additions to the server such that the
>>> autogenerated port isn't displayed in the form, eg the user is prompted
>>> to set the port or leave it at '0' after which the server will
>>> autogenerate it immediately before saving.
>>>       
>> Yes, that's the flow that makes sense.
>>     
>
> Does the user really need the ability to choose a specific port ? If there
> is a non-trivial number of VMs, any port they might wish to reserve for
> their own VM is probably already taken by another. With the ovirt-viewer
> client app, they should never need to know what port is used for a VM,
> since ovirt-viewer will automatically lookup the port for them.
>
> Daniel
>   

I would say its just another use case, eg since the default is to
autoassign the port, is there really any drawback to allowing an
administrator to manually set it?

I can see the autoassignment scenario being useful in large deployments
as you mentioned, but for smaller ones, I think a way to allow admin
defined / consistent  port assignments would be useful. If an
administrator chooses to override the autoassignment, and assign a port
already in use, the conflict will be due to a problem in his own
assignment schema. Also while I agree ovirt-viewer will take care of the
port internally, clients may wish to use their own vnc viewer (granted
the client accessable vnc uri is displayed in the vm's details pane).

Perhaps a better solution would be to add a config option to one of the
yml's (or even to the db on a pool by pool or other basis) to allow the
server administrator to allow or disallow manual vnc port assignment. I
can do whatever the requirements dictate, as the original reqs didn't
specify this either way, (removing the field from the form is pretty
straightforward and would probably make the controller logic a bit
simpler) , but any way will push this patch's review / ack / commit a
little while back.

   -Mo