[libvirt] [PATCH REPOST 4/5] admin: Introduce virAdmServerSetClientProcessingControls

[Erik Skultety]

>> diff --git a/src/rpc/virnetserver.c b/src/rpc/virnetserver.c
>> index 2cd1765..4c4b144 100644
>> --- a/src/rpc/virnetserver.c
>> +++ b/src/rpc/virnetserver.c
>> @@ -1044,3 +1044,37 @@ virNetServerGetClient(virNetServerPtr srv,
>>                         _("No client with matching ID '%llu'"), id);
>>      return ret;
>>  }
>> +
>> +int
>> +virNetServerSetClientProcessingControls(virNetServerPtr srv,
>> +                                        long long int maxClients,
>> +                                        long long int maxClientsUnauth)
>> +{
>> +    int ret = -1;
>> +    size_t max, max_unauth;
>> +
>> +    virObjectLock(srv);
>> +
>> +    max = maxClients >= 0 ? maxClients : srv->nclients_max;
>> +    max_unauth = maxClientsUnauth >= 0 ?
>> +        maxClientsUnauth : srv->nclients_unauth_max;
>> +
>> +    if (max < max_unauth) {
>> +        virReportError(VIR_ERR_INVALID_ARG, "%s",
>> +                       _("The overall maximum number of clients must be "
>> +                         "greater than the maximum number of clients waiting "
>> +                         "for authentication"));
>> +        goto cleanup;
>> +    }
> 
> Whoa, we don't have this check when creating new server. I guess we
> should do that.
> 

Well, you might be right, but then, let's say someone who has a
configuration with max_unauth > max updates to upstream and the daemon
just refuses to start because it is now considered invalid. I know that
we can't change the logic in a way that would make existing VMs
disappear, but what about daemon refusing to start because the original
configuration that used to work is now considered invalid? Should we
error out or just warn and modify the attributes, so that the '>'
constraint is met?

For now, I adjusted the patches according to your notes, except for this
one and sent v2. I would like to hear your opinion on this one, it's no
problem to make some final adjustment to the patch before it will be merged.

Erik