Virtualmin natively supports the management of multiple domains by a single user: this is done using sub-servers in combination with a virtual server. If a user has multiple domains, you simply create a virtual server with any one of the domains that the user needs to manage and the other domains can be associated with the corresponding number of sub-servers that you create under that virtual server. It is quite trivial to do so with Virtualmin.
But if you donāt want to use a domain name as the āmain accountā, Vrtualmin will accept, say, vending_makina as a login name and well as the virtual serverās domain name (yeah, I know, vending_makina is not a domain name but Virtualmin will accept it as one - letās call it a pseudo domain) and you can then use all the domains that you want the user vending_makina to manage as sub-servers of vending_makina pseudo domain.
Both approaches outlined above will also fulfill your requirement of a user being able to login with a single set of credentials to manage multiple domains in Virtualmin.
Yup i use that also in other panels , so Maindomain (āFakeā) user / admin / resellers makes it easier afterwards to move / sell the domains to other server / users und no need to make changes for the main default domain for such āusersā
Backup restore or moving users to other server you have to take care.
I use for pseudo ( if own ip adress ipv6 for user) also often extra subdomains from vps/ server domainname , so if server hostname is hst1.domain.com then fake1.domain.com ( other user then fake2.domain.com then dns and with those (ipās) and handy for the ptr reverse records. So then the domainnames are yes real but easy to handle switch / moves from the important WEB domains themself while not as a maindomain connected to useraccount. Separating here is handy.
Yes you can go the way with renaming , i donāt like that, sometimes not working or rests of it stay somewhere.
Virtualmin Pro includes a reseller account type which has the ability to create and manage top-level domains (and the admin user can move domains from one reseller to another or dis-associate them from a reseller). We figure if youāve got resellers, youāre making money with Virtualmin, and weād like to see a little bit of that money.
There are other ways to achieve the feel of a āuser that creates vhostsā rather than a āvhost that has associated vhostsā though, and Iāve talked about it in the past. You can create your first domain as username.yourdomain.com. e.g. joe.virtualmin.com, and then I login as joe.virtualmin.com and create my sub-servers. A sub-server can have all of the features of a top-level server (mail and everything else), it just lives within the home directory of the āparentā server.
History tells us our user model is a little confusing for folks. We were trying to make āI want a website->I have a websiteā as short as possible. But, turns out a lot of folks donāt think of it that way, and would rather the workflow start with a ācreate a website manager accountā step, and then get to the websites later.
As we go more cloud native in Virtualmin 7 and 8, we are going to have to rethink the user model. Itāll have to be in a database (LDAP or SQL or whatever), since services will no longer all run in one place. The complexity of this is dangerous, and I think itāll scare a lot of Virtualmin users off, though, so I donāt know the right thing. Our users are not, by and large, people that need a dozen servers to run their websites, so I donāt know exactly what a cloud native Virtualmin looks like (though weāve already added a lot more awareness of cloud-based services like DNS, with more of that coming). But, users definitely get a rethink, and I guess that probably means they get abstracted away from the website they manage.
But how about with permissions at file-system if we do this kind of setup?
Can subserver 1 see and access data of subserver 2.
If so, it might be a security-risk.
Exaggerated example:
You have 20 Wordpress Installation under this fake-user-account.
One is pretty old and was hackedā¦ this wayā¦ how high is a high risk, that hacker can access all other 19 WP in opposite to a config, where each domain has an separate Login?
Yep. Iām not recommending it. Iām saying itās a way to have everything owned by the same user.
Reseller created domains do not have this characteristic. They can each be top-level domains with their own user account. (But the reseller account does not have ssh/FTP access to the domains it manages, so you will need separate account details in your deployment process. But, best practices dictate an automated deployment via a revision control system or something where youād only need to set it up once.)
Then I also would not do it this way. Everybody who ever had to re-secure an hacked webspace knows, that the needed effort extremely raise by the number of each software installed on it.
@calport If you recommend / describe this way to archive āone-login for all Subserversā, you better should add a disclaimer to your recommendation so that the users can decide if itās worth the risk to use this workaround.
I donāt consider it ādangerousā, but itās also not really best practice. Itās a balancing act. Some people really donāt want to have multiple logins, which is the only way to do it āsafelyā by this definition. If you only have a bunch of simple sites, all running the same software in the same versions, the risk is not significantly elevated by having them owned by one user (they were all gonna be exploitable in the same ways, if any one was exploitable, anyway).
We use it for static and āparkedā or 301 redirect domains for example.
And for tests from versions and updates from some software before going live on main this then on subs with ip access protection.
I will try it next year 
