Vagrant builds VM's but cannot Locate them

The Vagrantfile

• Creates the VM's
• Creates the .vagrant directory and sub directories .vagrant/machines/hostname/parallels
• But the VM are showing up in the configured Parallels Virtual Machines Folder

top-agent (vagrant) >vagrant status
Current machine states:
nimbus not created (parallels)
supervisor1 not created (parallels)
supervisor2 not created (parallels)
zookeeper1 not created (parallels)

But they're showing up on in the UI

There must be a config param somewhere that's missing or not matching up?
vm.provider.location

Thanks

 

When creating the boxes I had vm.box on the outside the each loop for boxes.

​

 

Robert_Birch,
It is not so easy to figure out what is going wrong. Could you please show your Vagrantfile (or the simplified version of it, at least) ?

After VMs have been created, these folders should contain files with name "id", which content is a VM UUID. Is it so in your case?

 

Was this ever figured out?
I have one machine that vagrant + parallels is working on, and so for my work laptop I tried to do the same... however I now am only able to run:

Code:

vagrant up

Any subsequent vagrant commands (once it has finished spinning the machine up), I receive the following error message...

I have the vagrant parallels plugin installed and presumably at the latest version. I contacted Parallels directly, and they pointed fingers at vagrant and said to contact them... of which I am QUITE PISSED off about. I pay for Parallels and all I get is a non-helpful contact a tool that is only 1/3rd of the chain I'm using. Parallels has developed 2/3rds of the chain that I'm trying to use.

Please help! I have tried to compare the differences between the machines and I'm not really able to find anything significant. Vagrant Cachier is one version ahead on the machine having trouble.

Keep in mind it does actually spin the machine up, but I'm only able to do a destroy by id, any other vagrant commands show the error above.

Thanks,
JS

 

I have found that if I use:

Code:

vagrant global-status

I can then obtain the "id" of the box, and from there I can run:

Code:

vagrant <command> <id>

This will allow me to use this box, but I don't know why this is the case. I have tried making all the versions of the libraries the same between my two systems, and to no avail.

I look forward to a fix/response,
Jarvis

 

JarvisS, sorry for a big delay.

Ah, this really makes sense. It seems like Vagrant detect's the wrong name of provider by some reason: "Parallels" instead of "parallels".
It most likely that this is a global Vagrant problem (not Parallels-specific) and it is reproduced in the some rare cases.
I'd like to fix it, so please, help me to investigate this problem:
1) What box are you using? Is it one of our official boxes (https://atlas.hashicorp.com/parallels/boxes/) or your own?
If it is your own box, please show the content of the following file:

Code:

~/.vagrant.d/boxes/<box_name>/<box_version>/parallels/metadata.json

2) Please, collect the debug log during the first "vagrant up" by this command:

Code:

vagrant up --debug 2>debug_up.log

and then try to do some subsequent command:

Code:

vagrant ssh --debug 2>debug_ssh.log

You can send these logs to me by e-mail ([email protected]) or attach them to your support ticket which you've already created and just tell me this ticket number

3) After the first `vagrant up` you will see that directory ".vagrant" is created in the working directory.
Is there this file?

Code:

.vagrant/machines/<machine_name>/parallels

Or this one?

Code:

.vagrant/machines/<machine_name>/Parallels

 

Thanks for your response!

1. Y'alls box.
   
   Code:

   override.vm.box = "parallels/ubuntu-14.04"
   override.vm.box_url = "https://vagrantcloud.com/parallels/boxes/ubuntu-14.04"

2. I'll email them and attach to the support ticket.
3. The second one with the capitol P which I'm sure is the issue.

I appreciate the seriousness with which this is now being dealt with. The initial response from Parallels really left me wondering since it merely pointed the finger at Vagrant.

Look forward to the full resolution!
Jarvis

 

JarvisS, thank you very much!

Unfortunately, I don't have a success here yet. I've investigated your "debug_up" log and it looks OK, e.q. it tells that the correct name for data dir is using:

Code:

<workdir>/.vagrant/machines/default/parallels

So, it is unclear at the what moment the renaming "parallels" -> "Parallels" happens. Could you please try to reproduce it with a new "bare" VM?

Code:

cd /any_empty_folder
vagrant init parallels/ubuntu-14.04
vagrant up

Is this VM broken too? Is the folder name in ".vagrant/machines/default/parallels" capitalized to ".vagrant/machines/default/Parallels"?

 

This new bare VM isn't broken. This one is lowercase. Odd.
So I just went back through my Vagrantfile and it has nothing with an uppercase for the parallels.
Thoughts? Next steps?
Edit: So I decided to try to move the folder Parallels to parallels. This made everything work as expected. Now I have removed the parallels folder and am waiting for

Code:

vagrant up

at the moment.
Thanks,
Jarvis

 

So the vagrant up worked and re-created the lowercase .vagrant/machines/default/parallels folder. I have now removed that folder again and simply am trying to re-produce this issue by having run the following first...

Code:

vagrant up --provider=Parallels

The above failed with the same error message as my original problem. Now I have called a simple

Code:

vagrant up

and will report shortly how that went.

Edit: As I expected even though it (the above --provider=Parallels) failed, it created the .vagrant/machines/default/Parallels folder. I must have run that command first and then ran it without the provider argument. So is this something we need to report back to vagrant? The vagrant up worked, but I couldn't vagrant ssh into the box without specifying the id.

Thanks!
Jarvis

 

Jarvis, thanks for investigation!
Now we understood what the reason is. Actually, if the initial command will be wrong, with the capitalized provider ("--provider=Parallels") then folder ".vagrant/machines/default/Parallels" should not be left and have to be deleted. I'll report to Vagrant about this and even will try to send a pull-request with a fix.

As I've understood, it is working fine for you now, after renaming the folder to lower case. Can we consider that this issue resolved?

Conclusion:
In fact, HFS (the filesystem in OS X) is case insensitive by default and when we try to run the vagrant correctly, using "vagrant up" or "vagrant up --provider=parallels", then filesystem consider that the folder is already exists and continue to use it ("parallels" == "Parallels" for it). Thats why the first "vagrant up" is successful.
But after that, when we try to execute any secondary command like "vagrant ssh", Vagrant lists the machine folders and detects that it is already exists with some provider "Parallels", which is unknown.
The main point: Case insensitive is an evil