Description of problem: More of a feature request, but virsh should support regular expressions (at the VERY least, globbing- though regexes would of course be ideal)- especially for commands referencing a domain. And, even more ideally, extended regular expressions (if needed by the argument parser). e.g. for a list of domains such as: > PROD_projectname > projectname_devel > projectname_develv1 > projectname_develv2 > ... > projectname_develv20 and a command such as: > virsh # start|destroy|undefine|shutdown|etc. --regex 'projectname_devel\(v[1-3,5]\)?' > virsh # start|destroy|undefine|shutdown|etc. --eregex 'projectname_devel(v[1-3,5])?' Would perform the operation on the following domains only (and either in parallel or sequentially): > projectname_devel > projectname_develv1 > projectname_develv2 > projectname_develv3 > projectname_develv5 And non-matching domains would not have the operation applied to them (e.g. PROD_projectname, projectname_develv6, projectname_develv10, etc.) Version-Release number of selected component (if applicable): N/A, but I'm on 1.2.17 (on Arch x86_64) How reproducible: N/A Steps to Reproduce: N/A Actual results: Regexing/globbing/wildcards are not supported. Expected results: Implemented via a similar method above. Additional info: USE CASES: - Development vs. staging vs. production, etc. - Many libvirt implementations use relatively consistent names for enterprise environments as according to their function (e.g. auth_ldap.internal, auth_ldap.external, web_portal, web_bugtracker, etc.). - For uses of cross-distro/cross-operating system testing platforms for developers etc.
IMO the virsh 'shell' is really half baked... we should have never even added commands like pwd/cd/echo since it just motivates more requests like this, and it's never going to be a full featured shell. Really virsh is just a thin wrapper around the libvirt API, anything more than that should probably be in a different tool
Now, hold on. After 9 months, the only thing you have to say is comparing irrelevant shell-like commands to the request? I mention nothing about the "shell-like" functions- I mention a use case *specifically centered around starting/stopping groups of domains more easily*. Praytell, what sort of "requests like this" are you referring to? I don't want to run perl in the thing, I just want some way of managing more than one machine at a time with patterns using a tool meant to... manage more than one domain at a time on a virt platform on which there are likely multiple similarly-named domains. I fail to see what's so unreasonable about that, and I'd appreciate further input on what makes it such an unreasonable request. Do you mean to say it is unreasonable to ask that there were some sort of way of managing a multitude of guests aside from a bash loop? Because *that* strikes me as unreasonable. Would support for grouping be more reasonable? I'm not understanding the logic here.
I've thought about this kind of thing many times -- I think it'd be a low hanging fruit to make Virsh a lot more friendly. Acting on groups of domains is a pretty common thing to do, so why not do it?
apologies, that was hasty and impolite. I did a lot of bug cleanup yesterday and impatience got the better of me. particularly I got confused by the globbing thing after just triaging other bugs regarding virsh's poor shell mode. I agree that acting on groups of domains is a useful thing to do. The question is whether a) it will ever actually be implemented in virsh, b) it's reasonable to even add to virsh re: a), a request to this bug tracker isn't any guarantee that any core libvirt devs will work on it. the answer to 'why not do it' is because there's basically an endless pile of work to do, and no one with the combo of time+energy+skills has cared enough to do it yet. unless someone shows up on the list with patches (or pays someone to implement it) this will likely sit indefinitely re: b) there's an argument to be made that this doesn't even belong in virsh, from a maintenance point of view. virsh has very little 'smarts' besides being a dumb wrapper around the rather large libvirt API. even with very little smarts it clocks in at nearly 30000 lines of C code. to libvirt users, virsh may seem like the sensible place to do it, but many times over the years that someone has suggested adding some smarts to libvirt (like this type of globbing) one or more libvirt devs have said 'we really need a better shell written in a higher level language since adding these types of things to virsh in C is extra painful'. including things like machine readable output, expanded output for various commands, colorized output, better shell mode, higher level commands for specific functional tasks, etc. that's partly what I was trying to get at in my response In isolation this feature wouldn't be too much work, but if we add it for a few commands it won't be long until we get a request to add it for more/all commands, which is a giant chunk of work. which leads to the 'we need a better tool' argument. we can leave this open and see if anyone takes it up
Thank you for reporting this issue to the libvirt project. Unfortunately we have been unable to resolve this issue due to insufficient maintainer capacity and it will now be closed. This is not a reflection on the possible validity of the issue, merely the lack of resources to investigate and address it, for which we apologise. If you none the less feel the issue is still important, you may choose to report it again at the new project issue tracker https://gitlab.com/libvirt/libvirt/-/issues The project also welcomes contribution from anyone who believes they can provide a solution.