You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Directory set by --libvirt-provider-dir flag contains 3 subfolders (store, machines, images) currently.
It can create problem because machine store contains api.Machine objects which serve for managing of VM. Folders machines and images contains os images, empty disks and additional files for vm.
Root cause is shared volume, where libvirt-provider doesn't monitor capacity.
It means machines and os images can affects libvirt-provider logic and block creating of api.Machine objects.
Monitoring of volume capacity will discuss in issue: #182
Ideally solution doesn't exist because it depends on structure of host volumes/filesystem.
Simplest solution for us will do every subfolders in libvirt-provider-dir configurable with arguments and administrator can set it as he will need.
If we want to keep all information together in libvirt-provider-dir, we can use symlink.
Example:
I have host machine with 48cpu cores, 64gb ram and volume with libvirt-provider-dir has 100gb capacity.
i will create one machine with 2cpu, 2gb ram and os disk with size 10gb.
Later i will add additional empty disk with capacity 90gb.
Currently i have available 46cpu cores, 62gb ram and 0gb capacity in libvirt-provider-dir (ignore rounding problem)
I will create second machine but operation will fail because i cannot create file in libvirt-provider-dir/store/
But libvirt-provider will still report available capacity for machine classes because we don't monitor volume capacity.
Summary
Directory set by --libvirt-provider-dir flag contains 3 subfolders (store, machines, images) currently.
It can create problem because machine store contains api.Machine objects which serve for managing of VM. Folders machines and images contains os images, empty disks and additional files for vm.
Root cause is shared volume, where libvirt-provider doesn't monitor capacity.
It means machines and os images can affects libvirt-provider logic and block creating of api.Machine objects.
Monitoring of volume capacity will discuss in issue: #182
Ideally solution doesn't exist because it depends on structure of host volumes/filesystem.
Simplest solution for us will do every subfolders in libvirt-provider-dir configurable with arguments and administrator can set it as he will need.
If we want to keep all information together in libvirt-provider-dir, we can use symlink.
Example:
I have host machine with 48cpu cores, 64gb ram and volume with libvirt-provider-dir has 100gb capacity.
i will create one machine with 2cpu, 2gb ram and os disk with size 10gb.
Later i will add additional empty disk with capacity 90gb.
Currently i have available 46cpu cores, 62gb ram and 0gb capacity in libvirt-provider-dir (ignore rounding problem)
I will create second machine but operation will fail because i cannot create file in libvirt-provider-dir/store/
But libvirt-provider will still report available capacity for machine classes because we don't monitor volume capacity.
Basic example
--libvirt-provider-dir=/home/user/.libvirt-provider
These parameters below can be optional. If they aren't set, we will use current logic.
--libvirt-provider-dir-store=/var/lib/libvirt-provider/store
--libvirt-provider-dir-machines=/var/lib/libvirt-provider/machines
--libvirt-provider-dir-images=/var/tmp/libvirt-provider/images
Motivation
Minimize side effects of vms to libvirt-provider logic. Add more flexibility for administrator how can use libvirt-provider.
The text was updated successfully, but these errors were encountered: