Re: [vagrant-up] How to fix port collision?

[Mitchell Hashimoto]

Adnan,

On Thu, Aug 16, 2012 at 10:38 AM, Adnan Doric <astrona...@gmail.com> wrote:

Hello,

I've got this message when trying to run "vagrant up":

[default] VM already created. Booting if it's not already running...
[default] Clearing any previously set forwarded ports...
[default] Fixed port collision for 22 => 2222. Now on port 2200.
Vagrant cannot forward the specified ports on this VM, since they
would collide with another VirtualBox virtual machine's forwarded
ports! The forwarded port to 3000 is already in use on the host
machine.

Indeed I created another test VM with the port 3000 forwarded, and destroyed it afterwards, why vagrant is complaining about destroyed VM settings, and how to fix this please?
 

Vagrant detects this by actually enumerating _running_ virtual machines from VirtualBox (even virtual machines that are not managed by Vagrant). So Vagrant at this point is finding a running virtual machine that has these things forwarded. Are you sure the machine is actually destroyed?

If it is, this can possibly be a bug with Vagrant, but I'd need a repro case.

Best,

Mitchell

[Adnan Doric]

Hello Mitchell,

I looked into VirtualBox and indeed, the old destroyed VM was still referenced there even though I destroyed it, it was successfully deleted from VirtualBox VM folder: C:\Users\Astronaute\VirtualBox VMs.

So I opened the C:\Users\Astronaute\.VirtualBox\VirtualBox.xml and it was also referenced there in MachineRegistry. I thought that the problem would be solved by removing the broken link to the VM from the VirtualBox: I removed it and checked the VirtualBox.xml, the broken VM was not referenced anymore so I tried to create another VM using vagrant and bam: Vagrant correctly added the new VM into the VirtualBox.xml but also added back the broken link VM.

I also tried to change the defaultMachineFolder somewhere else hoping that would solve the problem, but each time I run "vagrant up", it keeps setting the value back to the old one and adds the broken MachineEntry.

Now I would like to know where the Vagrant is pulling this info from in order to modify it at the source?

I hope it is clear, if not ask for more info,
Thank you :)

[Mitchell Hashimoto]

Hi,

On Thu, Aug 16, 2012 at 11:31 AM, Adnan Doric <astrona...@gmail.com> wrote:

Hello Mitchell,

I looked into VirtualBox and indeed, the old destroyed VM was still referenced there even though I destroyed it, it was successfully deleted from VirtualBox VM folder: C:\Users\Astronaute\VirtualBox VMs.

So I opened the C:\Users\Astronaute\.VirtualBox\VirtualBox.xml and it was also referenced there in MachineRegistry. I thought that the problem would be solved by removing the broken link to the VM from the VirtualBox: I removed it and checked the VirtualBox.xml, the broken VM was not referenced anymore so I tried to create another VM using vagrant and bam: Vagrant correctly added the new VM into the VirtualBox.xml but also added back the broken link VM.

I also tried to change the defaultMachineFolder somewhere else hoping that would solve the problem, but each time I run "vagrant up", it keeps setting the value back to the old one and adds the broken MachineEntry.

Now I would like to know where the Vagrant is pulling this info from in order to modify it at the source?

Vagrant actually isn't pulling any information. This file is completely managed by VirtualBox, Vagrant simply tells VirtualBox "import this VM," "boot this VM," etc. And Vagrant only tells it to do those things for the VMs in its current environment (where the Vagrantfile is). This seems like VirtualBox is doing something weird.

Best,

Mitchell

[Bradley Holbrook]

If a vagrant UP is interrupted or the batch job is manually stopped in the middle, the VM machine folder is left intact which is what causes the problem. The machine won't actually show up in VirtualBox though. Simply deleted the folder and you should be able to vagrant up without a collision.