Hi there, Maybe we could try to replicate the 'onehost disable' behaviour. That is, a disabled system DS would be ignored by the scheduler, but you can still deploy VMs manually there.
What do you think? Should I open a ticket for this? Regards -- Carlos Martín, MSc Project Engineer OpenNebula - Flexible Enterprise Cloud Made Simple www.OpenNebula.org | cmar...@opennebula.org | @OpenNebula<http://twitter.com/opennebula><cmar...@opennebula.org> On Mon, Feb 17, 2014 at 4:52 PM, Stefan Kooman <ste...@bit.nl> wrote: > Quoting Daniel Dehennin (daniel.dehen...@baby-gnu.org): > > Stefan Kooman <ste...@bit.nl> writes: > > > > > > [...] > > > > > You can, in your vm template you can put the following: > > > > > > SCHED_DS_REQUIREMENTS="NAME=NAMEOFYOURTESTDATASTORE". All other DS'es > > > will be filtered out. > > > > This will force a VM to use this one when it have this > > SCHED_DS_REQUIREMENTS, but what about all other VMs which do not have > > any requirements set? > > > > As far as I understand, they will use it too. > > They might use it. It depends on the policy set on the DS (packing, > striping or custom) [1]. You have to set the requirement on each and > every vm (template) to make sure they end up in the correct datastore. > See sched.log to see what priorities your datastores end up with. Our > datastores end up with the same priority and the first one in the list > gets chosen. > > Gr. Stefan > > [1]: > > http://docs.opennebula.org/stable/administration/storage/system_ds.html?highlight=system%20datastores > > > > > > > [...] > > > > > Actually I was looking for this as well :). For example I would like to > > > be able to "link" certain datastores to "groups", i.e. use datastore A > > > for group A by default instead of having it defined in every single > > > template. If users of group A have the possibility to define their own > > > templates and they would forget the "SCHED_DS_REQUIREMENTS" to their > > > datastore it would end up somewhere else (if at least they have enough > > > rights on other (system) datastores). Basically it would be nice to > have > > > even more filtering capabitilites to ensure correct > > > placement/deployment. > > > > If I remember correctly, I heard about some group and resource providers > > mechanisms for 4.6, it may address this. > > > > Regards. > > > > -- > > Daniel Dehennin > > Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF > > Fingerprint: 3E69 014E 5C23 50E8 9ED6 2AAD CC1E 9E5B 7A6F E2DF > > > > > _______________________________________________ > > Users mailing list > > Users@lists.opennebula.org > > http://lists.opennebula.org/listinfo.cgi/users-opennebula.org > > > -- > | BIT BV http://www.bit.nl/ Kamer van Koophandel 09090351 > | GPG: 0xD14839C6 +31 318 648 688 / i...@bit.nl > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iF4EAREIAAYFAlMCMEoACgkQTyGgYdFIOcbqOwEAjnynlt3OOcgnm+c4FoVA22uj > q6mKLNQ4iW5QqaGthhcBAJxYt3gkqWRP3iXV/rPME0/Bq/ZOm8UVpEa9PEqIBO7h > =tDzh > -----END PGP SIGNATURE----- > > _______________________________________________ > Users mailing list > Users@lists.opennebula.org > http://lists.opennebula.org/listinfo.cgi/users-opennebula.org > >
_______________________________________________ Users mailing list Users@lists.opennebula.org http://lists.opennebula.org/listinfo.cgi/users-opennebula.org