Add numa to dedicated

[ljelinkova]

When using dedicated cpu policy together with numa, the numa pinning should be created when the vm starts and
cleared when the vm shuts down.

[ljelinkova]

I implemented the pinning so that it is stored into the database, but I wonder, if it would not be better to create a "runtime" pinning, similar to the "runtime" cpu pinning as mentioned here #180

There are 2 reasons:

• the current implementation allows one virtual node to be pinned to more physical nodes. However, the UI cannot display that
• with addition of the validation, that the numa nodes cannot be manually pinned together with the dedicated policy, it will be impossible to edit a running VM because the running VM's nodes will be pinned when using dedicated policy

[liranr23]

I implemented the pinning so that it is stored into the database, but I wonder, if it would not be better to create a "runtime" pinning, similar to the "runtime" cpu pinning as mentioned here #180

There are 2 reasons:

• the current implementation allows one virtual node to be pinned to more physical nodes. However, the UI cannot display that

I never did that, I am unsure if we wish that at all. I am unaware of the pros and cons of this. Out of curiosity does it pass NumaValidator::checkVmNumaNodesIntegrity()?

• with addition of the validation, that the numa nodes cannot be manually pinned together with the dedicated policy, it will be impossible to edit a running VM because the running VM's nodes will be pinned when using dedicated policy

Here we probably need to loose the validations to let it change somehow (VM status?).

A general answer about making the NUMA configuration dynamic:
We thought about it already when implementing resize and pin, this is really costy as NUMA configuration is built upon multiple DB tables and many fields, it's not a single field addition into a dynamic table.
However it is probably possible to be done and then serialize/deserialize it.
Since we know the vNUMA exists, we don't add/remove any new and we do know it's not pinned anywhere - we do the pinning and unpinning ourselves - I don't really see the point of not using the static data.
But, since we know the initial state and leaving it back to the same state I think it's OK to use it as is.

[ahadas]

I implemented the pinning so that it is stored into the database, but I wonder, if it would not be better to create a "runtime" pinning, similar to the "runtime" cpu pinning as mentioned here #180
There are 2 reasons:

• the current implementation allows one virtual node to be pinned to more physical nodes. However, the UI cannot display that

I think it's not a justified reason to change it as libvirt seems to accept such a configuration

I never did that, I am unsure if we wish that at all. I am unaware of the pros and cons of this. Out of curiosity does it pass NumaValidator::checkVmNumaNodesIntegrity()?

• with addition of the validation, that the numa nodes cannot be manually pinned together with the dedicated policy, it will be impossible to edit a running VM because the running VM's nodes will be pinned when using dedicated policy

Here we probably need to loose the validations to let it change somehow (VM status?).

That's one option - to say that when a vm is not down and it has dedicated policy then the numa pinning represent generated rules, otherwise those rules were specified manually if exists
But I like the concept of separating out the runtime NUMA pinning because we won't find ourselves operating on the table of the vnodes in all those places related to vm-lifecycle

A general answer about making the NUMA configuration dynamic: We thought about it already when implementing resize and pin, this is really costy as NUMA configuration is built upon multiple DB tables and many fields, it's not a single field addition into a dynamic table. However it is probably possible to be done and then serialize/deserialize it. Since we know the vNUMA exists, we don't add/remove any new and we do know it's not pinned anywhere - we do the pinning and unpinning ourselves - I don't really see the point of not using the static data. But, since we know the initial state and leaving it back to the same state I think it's OK to use it as is.

Back then we thought of serializing the entire structure we have in the database which was a more complicated scenario that this, IIUC what Lucia has in mind - representing just the relation between the existing virtual and physical resources that already exist in the database (and let's say assuming that the tune is STRICT in that case). I guess it could have the same syntax of the cpu pinning field, no?

I'm just afraid we do this a bit too late - we also need to change the pinning logic to of the dedicated CPUs with vNUMA topology, right?

[ljelinkova]

/ost

[ljelinkova]

/ost