{"id":18825423,"url":"https://github.com/grycap/vmca","last_synced_at":"2026-01-21T00:30:16.135Z","repository":{"id":29255005,"uuid":"32787564","full_name":"grycap/vmca","owner":"grycap","description":"Virtual Machine Consolidation Agent - An agent to automatically migrate VMs between hosts, to get hosts empty from VMs","archived":false,"fork":false,"pushed_at":"2016-10-06T07:52:47.000Z","size":200,"stargazers_count":3,"open_issues_count":0,"forks_count":0,"subscribers_count":6,"default_branch":"master","last_synced_at":"2024-12-30T04:56:04.949Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-3.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/grycap.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2015-03-24T09:02:38.000Z","updated_at":"2021-10-01T14:35:46.000Z","dependencies_parsed_at":"2022-09-09T23:51:49.388Z","dependency_job_id":null,"html_url":"https://github.com/grycap/vmca","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/grycap%2Fvmca","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/grycap%2Fvmca/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/grycap%2Fvmca/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/grycap%2Fvmca/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/grycap","download_url":"https://codeload.github.com/grycap/vmca/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":239763667,"owners_count":19692800,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-08T00:59:24.734Z","updated_at":"2026-01-21T00:30:16.041Z","avatar_url":"https://github.com/grycap.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Virtual Machine Consolidation Agent\n\nDuring the lifecycle of a private Cloud deployment, the Virtual Machines (VM) are placed in real virtualization hosts. When these VMs are no longer needed, they are destroyed and their resources are freed. The problem here is that due to these movements, we can find that the remaining VMs at a moment are spreaded among the real hosts resulting in a low density of VM per real host. The consequence is that is get a fragmentation of the resources of the virtualization hosts. Such fragmentation may have critical effects if a new VM should be started but there are not enough continous resources to be allocated, while there exist fragmented resources.\n\n![IMAGE](https://github.com/grycap/vmca/blob/master/img/fragmented.jpg?raw=true =200x)\n\nOn the other hand, when the fragmentation of resources happens, another consequence is an inefficient usage of the virtualization resources. That means that we are probably keeping powered on some real hosts because they are running VMs. In case that these VMs were hosted in other hosts, some of the virtualization hosts may be powered off to save energy.\n\nThe Virtual Machine Consolidation Agent (VMCA) inspects your private Cloud deployment to try to defragment the available resources by migrating VMs from some real hosts to other real hosts that have enough resources to keep all the VMs running. The result is a compression of the existing free resources and an increase of the density of VMs per real host.\n\n![IMAGE](https://github.com/grycap/vmca/blob/master/img/defragmented.jpg?raw=true =200x)\n\nOne of the main objectives of the VMCA is getting real hosts free from VMs. Using this agent in conjunction with CLUES it is possible to achieve a more efficient usage of the resources. Moreover we will save energy because those nodes that are not used by the virtualization platform will be powered off by CLUES.\n\n## Evacuating hosts\n\nUnder some circumnstances, some hosts need to be powered off, rebooted, etc. due to maintenance. This is a problem when that host has some VMs running on it. VMCA can also be used to move the VMs from one host to the other hosts in the platform. Finally, when the host is free of VMs it can be powered off.\n\nOpenStack has a similar function called ```host-evacuate```, but it is needed to move all the instances from one specific host to exactly one host. VMCA will try to re-place the VMs using a deffragging algorithm (e.g. packing the VMs into the less number of hosts, distributing them, etc.). \n\n# Installing\n\nVMCA is currently working in conjunction with OpenNebula (it has been tested with ONE 4.8). Futher releases will integrate with OpenStack.\n\n## Dependencies\n\nMake sure that you have installed ```cpyutils``` package from https://github.com/grycap/cpyutils\n\n## Installing\n\nYou have to obtain the source code in a temporary folder and execute (as root):\n\n```\n$ cd /tmp\n$ git clone https://github.com/grycap/vmca\n$ cd vmca\n$ python setup.py install --record installed-files.txt\n$ cp ./etc/vmca.cfg-example /etc/vmca.cfg\n$ chmod 600 /etc/vmca.cfg\n$ touch /var/log/vmca.log\n```\n\nIn particular, to integrate with ONE, you will need to have one user in the ```oneadmin``` group (e.g. vmcauser).\n\n```\n$ oneuser create vmca vmcapass\n```\n\nNow you should adjust the file ```/etc/vmca.cfg``` to your settings. In particular, to work with ONE you will need to set the ```ONE_XMLRPC``` and ```ONE_AUTH``` variables.\n\nOnce ready, you can start VMCA by simply executing\n\n```\n$ vmcad start\n```\n\n## Debugging (in case that it does not start)\n\nYou can see what happens in ```/var/log/vmca.log```. In case that you cannot make vmca run, you can set ```LOG_FILE=``` in the configuration file and start vmca.py using the commandline ```vmca.py```\n\n## Running VMCA as other user\n\nIf you want to run VMCA with other user than root, you must give the permissions to the ```/etc/vmca.cfg``` and ```/var/log/vmca.log``` files, by executing (as root):\n\n```\n$ chown vmcauser:root /etc/vmca.cfg /var/log/vmca.log\n$ chmod 644 /var/log/vmca.log\n$ chmod 600 /etc/vmca.cfg\n```\n\nThen you should modify the command ```vmcad``` to start the application as other user.\n\n## Installing as source-code\n\nYou simply have to choose a folder in which VMCA is being installed (for now on it will be /usr/local/vmca) and execute (as root):\n\n```\n$ cd /usr/local\n$ git clone https://github.com/grycap/vmca\n$ cp vmca/etc/vmca.cfg-example /etc/vmca.cfg\n$ chmod 600 /etc/vmca.cfg\n$ touch /var/log/vmca.log\n```\n\nIn particular, to integrate with ONE, you will need to have one user in the ```oneadmin``` group (e.g. vmcauser).\n\n```\n$ oneuser create vmca vmcapass\n```\n\nNow you should adjust the file ```/etc/vmca.cfg``` to your settings. In particular, to work with ONE you will need to set the ```ONE_XMLRPC``` and ```ONE_AUTH``` variables.\n\nOnce ready, you can start VMCA by simply executing\n\n```\n$ python /usr/local/vmca/vmca.py\n```\n\n## Running VMCA as other user\n\nIf you want to run VMCA with other user than root, you must give the permissions to the ```/etc/vmca.cfg``` and ```/var/log/vmca.log``` files, by executing (as root):\n\n```\n$ chown vmcauser:root /etc/vmca.cfg /var/log/vmca.log\n$ chmod 644 /var/log/vmca.log\n$ chmod 600 /etc/vmca.cfg\n```\n\nThe you can su as the ```vmcauser``` user and start VMCA.\n\n# Using VMCA\n\nThe standard distribution of VMCA incorporates the ```vmca``` CLI application, and the help of the command is very self-explanatory:\n\n```\n# vmca --help\nThe VMCA command line utility\n\nUsage: vmca [-h] [getplan|forcerun|clean|version|info]\n\n\t[-h|--help] - Shows this help\n\t* Gets the current migration plan that is being carried out in the server\n\t  Usage: getplan \n\n\t* Forces VMCA to analyze the platform immediately\n\t  Usage: forcerun \n\n\t* Migrates all the VMs from one host\n\t  Usage: clean [-f] [-e] \u003cnode\u003e\n\t\t[-f|--force] - Force cleaning even if the host has not its VMs in a stable state\n\t\t[-e|--use-empty] - Use emtpy hosts as a possible destinations\n\t\t\u003cnode\u003e - Name of the host that is going to be cleaned\n\n\t* Gets the version of the VMCA server\n\t  Usage: version \n\n\t* Gets the monitoring information that has the VMCA server\n\t  Usage: info \n```\n\n## Evacuating a host\n\nIn case that you want to power off a host, or you need to reboot it, you can move all its VMs to other hosts using VMCA. As an example, if you want to move all the VMs from 'torito03', the commandline will be:\n\n```\n# vmca clean torito03\n```\n\nThe default behaviour of VMCA is not to use the hosts that are empty (as it tries to get hosts without any VM running on them). You can modify such behaviour and enable VMCA to use the empty hosts including the flag ```-e```.\n\n# Scenarios\n\n## VMCA is only needed to ocasionally evacuate hosts\n\nYou can disable the periodical run of the deffragger by setting ```ENABLE_DEFRAGGER=False``` in the VMCA configuration file. Then the VMCA deffragger will never be automatically triggered, while it can be forced using the commandline.\n\n## The deffragger used to evacuate a host has to be different than the one used automatically\n\nIn some cases you will need different defraggers for different purposes. E.g. you need an automatically defragger that packs the VMs into the hosts, but you want that when a host is evacuated, its VMs are homogenously distributed in the platform.\n\nWhile it is possible to implement in VMCA, currently there is not any _configuration based_ mechanism to make it. The solution is a bit tricky, as it is needed to modify the source-code to select which defragger will be used for each purpose.\n\nYou should modify the file ```vmcad.py``` and locate the line that creates the daemon:\n\n```\nDAEMON = vmcaserver.Daemon(deployment, T(), T_clean())\n```\n\nThe parameters for the Daemon class are the deployment (e.g. the ONE based), the automatic defragger (```T``` in the default implementation, and the defragger used to clean one host (```T_clean``` in the default implementation).\n\nYou can create your own class or use a combination of the available criteria, as ```T``` and ```T_clean``` are created:\n\n```\n    class T(schedule.Scheduler_Packing, firstfit.SelectHost_LessVMs_First, firstfit.Defragger_FF): pass\n    class T_clean(schedule.Scheduler_Stripping, firstfit.SelectHost_LessVMs_First, firstfit.Defragger_FF): pass\n```\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgrycap%2Fvmca","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fgrycap%2Fvmca","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgrycap%2Fvmca/lists"}