How do KVM Ports for KVM guests get assigned?

Okay, so it's late and I admit to being a little confused.

I just moved a largish KVM VPS from one host to another. The transfer went apparently just fine, but the VPS refused to start after the transfer, apparently because it is trying to use the same port for the KVM console as another VPS that is already running - when you try to start it it complains that port 40000 is in use and won't bind to it. And indeed, one of the other VPS's on the same server is already using 40000

I temporarily shut down the conflicting VPS (because it was less crucial to life than the one that would not start) and now the moved VPS will start up fine. But of course now the OTHER one will not start because of the conflicting port.

I managed to work around THAT by just starting the VPS completely by hand and changing it to an unused port.

But my question here is where do the port numbers come from? Shouldn't there be a mechanism to ensure that two VPS systems on the same machine won't try to use the same port? Looks like I cannot figure out any way to actually fix this in the long run.

Also --- one last question that's more general ---- why does Cloudmin do all of this by using the KVM commands directly rather than using the more established mechanisms in the OS??? It makes running KVM on Cloudmin sort of a special case that is not like how most systems work.

Status: 
Closed (fixed)

Comments

Yes, Cloudmin should assign non-conflicting ports. Was the VM that the port clashes with also managed by Cloudmin?

Two different KVM VPS's on the same physical server. Both under Cloudmin control. When started from Cloudmin both try to start with port 40000 assigned for KVM -- so the second one started will not start up. One further piece of info --- the VPS I moved to this server is the one I was having the problem with in my last issue, where it had "disappeared" from Cloudmin control on its old Physical Server because it had lost it's --name flag. After I moved that to the new physical server (and that went fine) it apparently also got a conflicting KVM port. This would be the issue at https://www.virtualmin.com/node/40991

I guess I'd like to understand where the mechanism is that assigns the KVM ports, and how I can change the KVM port on one or the other of the 2 VPS's so they will both start up under control of Cloudmin.

I still really would like to have a better understanding of the port assignment process, and how I could fix it for this somewhat messy VPS - I'd love to be able to do restarts, etc. through Cloudmin, and it still seems to insist on sharing the same port number with another VPS on the same machine.

Does your host system have the lsof command installed? Cloudmin uses that to find TCP ports that are in use.

lsof is installed on the server, though I have to admit that I am not COMPLETELY sure it was installed at the time I last tried to reboot one of the 2 vps systems that are trying to use the same port. I can probably try this out again.

Is it therefore the case that the ports are assigned at BOOT time ? I'm a little confused there because the ports seem to be defined in the startup file when the server boots, but I'm not clear on the mechanism where re-starting the VPS's individually.

No, the ports aren't assigned at boot time - they are chosen when the VM is created based on what all existing known VMs are using, and which ports are available (according to lsof) on the host. The only case in which I could see this going wrong is if there was a VM running that was unknown to Cloudmin at the time the clashing one was created.

I guess the question remains -- what can I do to fix this situation where Cloudmin is assigning the same port to two different VPS's --

Worst case, you can do the following :

1 - Shut down the VM

2 - SSH into your Cloudmin system as root , and get the VM's unique ID with the command cloudmin list-systems --host your-vm-name --id-only

3 - Edit the file under /etc/webmin/servers named based on that ID

4 - Change the kvm_monitor= line in that file

That was what I was looking for and helps a lot.

Status: Active ยป Closed (fixed)