How to properly uninstall VVV?

[cagross]

What is the suggested method of completely uninstalling VVV from my computer?

Expected Behavior

N/A

Current Behavior

N/A

Possible Solution

I assume I will need to uninstall both Vagrant and Oracle VM VirtualBox. Is there anything else I need to uninstall? What about files/directories to manually remove--are there any? Are there considerations I have to take with my Windows hosts file (or any other files)?

Steps to Reproduce (for bugs)

N/A

Context

In this case, I would like to uninstall VVV so I can in-turn re-install it from scratch. I think one or more of the supporting programs may have become corrupted on my computer (due to an unrelated issue with my operating system).

Your Environment

• VVV version: 2.2.0
• VVV Git Branch:
• Vagrant version: 1.8.6
• VM Provider name: VirtualBox
• VM Provider version: 5.1.30
• Operating System and version: Windows 10, x64

Thank you.

[tomjn]

In this case, I would like to uninstall VVV so I can in-turn re-install it from scratch.

Then you have 2 options:

• vagrant halt
• vagrant destroy

Halt will turn off the VM, at which point you can then uninstall and reinstall Vagrant and vagrant plugins.

Destroy will delete the VM in Virtualbox, but keep in mind uninstalling Virtualbox will do this anyway, and there's no difference when uninstalling and reinstalling Vagrant anyway.

The actual VVV folder itself needn't be deleted for what you're trying to do, but if you really want to uninstall VVV completely, delete the VM and the VVV folder. You might also want to remove the box used, see the troubleshooting part of the docs for a block of commands that will do that and then re-setup VVV

Also keep in mind that VirtualBox 5.1.3.x and Vagrant 2.0 running under Windows has a networking bug, I'd recommend using the highest version of 5.2.x you can get, and uninstalling Vagrant before upgrading to 2.0

[tomjn]

Also, if you're encountering issues, copy paste them here, I might be able to point you in a specific direction

[cagross]

Thanks very much for the reply.

Also, if you're encountering issues, copy paste them here, I might be able to point you in a specific direction

OK, I'm up for that. Per your suggestion, before carrying out any uninstall steps, I had a look at the "Starting from Fresh" instructions on the Troubleshooting page. I tried following the instructions, but encountered an error with the first step (git pull). If you're up for it, I'd love to walk through those steps with you and resolve resolve any issues.

Before we get too sidetracked though, how about we mark this particular issue as resolved so I can then open a new one with my specific git pull issue? Does that sound reasonable? Or should we carry on our discussion here? I'll defer to you and/or the mods on how to proceed..

Thanks.

edit: I actually resolved my git pull issue, but have another question regarding updating Vagrant.

[tomjn]

hmmm what issue are you encountering updating Vagrant? Have you used the uninstaller then reinstalled or did you install over the top of an older version?

[cagross]

Have you used the uninstaller then reinstalled or did you install over the top of an older version?

I actually didn't follow any of your uninstall steps (sorry!). I saw the Starting from Fresh instructions and decided to first have a go at them. From those instructions, I ran:

git pull vagrant halt vagrant destroy

all without issue. I then ran vagrant box update and it completed without issue. But shouldn't this step have updated my version of Vagrant to the latest version (v 2.0.1)? If I check my current Vagrant version, it is still v1.8.6. Or am I misunderstanding something?

I have not carried out any of the remaining steps. I wanted to first understand what was happening here.

[tomjn]

vagrant box update doesn't upgrade Vagrant itself, it updates the box used as a base for the VM, in this case the Ubuntu box. When you provision the VVV box it doesn't start from an empty container, it starts from a pre-filled box with an install of Ubuntu, destroying and reprovisioning VVV lets you use the updated box with whatever security updates have been pulled down in the new Ubuntu box

To update Vagrant itself you need to download it from vagrantup.com

[cagross]

OK thanks for that info. Progress is being made, slowly but surely.

To update Vagrant itself you need to download it from vagrantup.com

I did this, and in the process confirmed that my installation of Vagrant had become corrupt. I was able to uninstall it, then install the latest version. I also updated Oracle VM to the latest version as well (v5.2).

On the next step though (vagrant plugin install vagrant-triggers vagrant-vbguest vagrant-hostsupdater), an error was returned:

$ vagrant plugin install vagrant-triggers vagrant-vbguest vagrant-hostsupdater
Installing the 'vagrant-triggers' plugin. This can take a few minutes...
Bundler, the underlying system Vagrant uses to install plugins,
reported an error. The error is shown below. These errors are usually
caused by misconfigured plugin installations or transient network
issues. The error from Bundler is:

conflicting dependencies ffi (= 1.9.18) and ffi (= 1.9.14)
  Activated ffi-1.9.14
  which does not match conflicting dependency (= 1.9.18)

  Conflicting dependency chains:
    ffi (= 1.9.14), 1.9.14 activated

  versus:
    ffi (= 1.9.18)

  Gems matching ffi (= 1.9.18):
    ffi-1.9.18-x64-mingw32

Thoughts? Should I try to resolve these? If so, how?

[tomjn]

This is the uninstall reinstall problem, upgrading to Vagrant 2.0 can do this if you don't do it cleanly. Uninstall Vagrant completely then install Vagrant 2.0

[cagross]

Uninstall Vagrant completely then install Vagrant 2.0

That's actually what I did in this case--I uninstalled my existing Vagrant, then downloaded and installed the latest version. I can try it again though for posterity if you think it will help.

[tomjn]

If it worked for you then great, it's just a cleaner way of doing the same thing. I've documented it on the main site, so I'm going to close this out for now

[cagross]

If it worked for you then great, it's just a cleaner way of doing the same thing.

Sorry for the confusion. But what I was trying to say was that I already carried out full uninstall/reinstall of Vagrant, and I'm still experiencing the plugin install error. I can open a new issue about it if you'd like.

[tomjn]

I think some research and investigation is needed, tbh I'm not sure what else I can advise as it's a general Vagrant problem, not something specific to VVV. It sounds like when uninstalling Vagrant it doesn't completely uninstall everything, either that or there's some Ruby based shenanigans going on with your machine that's not detailed here

[cagross]

it's a general Vagrant problem, not something specific to VVV.

OK that statement is helpful actually. Perhaps I can try posting to a general Vagrant forum (e.g. the Vagrant Google Group).

[cagross]

Sorry for re-opening this, but I wanted to get some clarification on the uninstall steps you gave earlier. To be clear, I'm looking to completely uninstall VVV, all of its components, and remove all associated files (so i can re-install). Would it be sufficient to carry out these steps:

• Uninstall VirtualBox (since this will carry out a vagrant destroy)

• Uninstall Vagrant.

• Delete my VVV folder.

• Ensure the C:\Users\\VirtualBox VMs folder is deleted (as per the Troubleshooting documentation).

Would that be a complete uninstall, or would I be missing anything?

To be clear, I'm doing this as part of troubleshooting related to this previous issue I raised about long TTFB. I just created a new VVV site from scratch, and began to experience the same issue, this time after installing the Avada theme. So as a last ditch effort, I'm going to try a complete uninstall and re-install, and see if that doesn't resolve the issue.

[tomjn]

• Uninstall VirtualBox (since this will carry out a vagrant destroy)
• Uninstall Vagrant.

These steps are a tad over the top, and a bit like removing the bottom 2 layers of a Jenga tower, it's anything but clean ( which appears to be your goal. vagrant destroy lets Vagrant do all the cleanup it needs, but by removing VirtualBox first, you mess with that. Treat it like an Onion, you've built layers up, so tear them down in the right order, don't start at the foundations first, it's messy

I just created a new VVV site from scratch, and began to experience the same issue, this time after installing the Avada theme.

Of course switching from a default theme to Avada will make things slower. There are faulty expectations at play here. VVV performance is not linear, nor is any other host. They all have things they excel or not excel at, much like some cars have better torque, some have better breaks, some are faster, some are more efficient. Avada will be doing things other themes don't, those might not play to the strengths of your local machine.

For example, some users take a very long time to provision VVV due to spinning mechanical disks. Others don't have good network connections ( or antivirus and firewalls that meddle with it ).

Some themes are faster than others, and they're faster or slower for different reasons. You will never get identical performance to a remote host, or even between remote hosts, and the chances of a complete refresh uninstalling VirtualBox Vagrant etc changing this are low in the extremes.

I know you want it to be just as fast, but you are at the mercy of what the code does, and the local hardware available to you. Fundamentally though, you have yet to actually identify what is slow beyond a Product name, except in scenarios where I would expect it to be slow for any or all hosts purely because of the way it was done ( e.g. remote requests, your computer isn't in a data centre on an internet backbone so of course a request to Instagram will be much slower than from say a SiteGround or GoDaddy server, if only because there's a greater number of hops, eitherway it's bad on all hosts ).

I know it's frustrating, and your main reason for using local dev environments is it's faster than developing in production (there are many other good reasons to use local dev), but I don't think you have realistic expectations, and there are so many unknown variables. For all I know your machine has lots of RAM and you've 10 other environments running in the background. You might have 200 chrome tabs open ( easily done ), a strange filesystem, or even that you never bothered to install the Oracle VirtualBox Extension pack and it's interacting strangely.

In all likelihood the culprit is that you didn't spend $2000 on a server grade CPU, but you're comparing your local computers CPU to that of a dedicated server with 5x as many CPU cores and much greater processing power that can juggle 100 sites effortlessly on a streamlined server OS that doesn't have to render a window manager etc. Production is fast for some things especially when you have it optimised for a particular task

We already know for a fact that a handful of cases you've mentioned are down to poor developer practice by the plugin author, or doing things that fundamentally aren't fast. Right now unless you can identify something specific ( and not a product or brand name ), there really isn't much that can be done short of getting faster hardware. I need to see something specific, to know that Avada is slower than 2019 really doesn't tell me much, what is it doing that's slower? Which part of Avada specifically? Can it be isolated down to a specific function? And replicated locally without needing things such as remote requests or stupidly expensive queries? If it is queries, can you time them and compare them against other results in equivalent environments? E.g. Chassis, Docker, MAMP, etc. There's too much feeling, lots of super high level general data, no specifics.

---

The TLDR:

If you want to remove a VVV install:

1. Run vagrant destroy
2. Remove the VVV folder

That should be all that's necessary. Reinstalling VirtualBox and Vagrant is for when either of them are broken, do not expect performance gains from doing it. Updating them and VVV to the latest versions might do that, but no guarantees.

[cagross]

If you want to remove a VVV install:

1. Run vagrant destroy
2. Remove the VVV folder

OK thanks.

Right now unless you can identify something specific ( and not a product or brand name ), there really isn't much that can be done short of getting faster hardware. I need to see something specific, to know that Avada is slower than 2019 really doesn't tell me much, what is it doing that's slower? Which part of Avada specifically? Can it be isolated down to a specific function? And replicated locally without needing things such as remote requests or stupidly expensive queries? If it is queries, can you time them and compare them against other results in equivalent environments? E.g. Chassis, Docker, MAMP, etc. There's too much feeling, lots of super high level general data, no specifics.

Tom, in the other issue we spent a lot of time troubleshooting. So what I'm doing right now is not re-asking you to help me troubleshoot the same issue, nor am I here to complain about anything. All I want to do now is try a fresh re-install. If that doesn't work, then I'll unfortunately resign myself to the fact that VVV isn't a viable option for me.

but I don't think you have realistic expectations,

Perhaps that is indeed the case.

and there are so many unknown variables. For all I know your machine has lots of RAM and you've 10 other environments running in the background. You might have 200 chrome tabs open ( easily done ), a strange filesystem, or even that you never bothered to install the Oracle VirtualBox Extension pack and it's interacting strangely.

I'm happy to answer any and all questions about my hardware and setup. I don't believe you ever asked me any such questions in the other issue. I know you wanted me to carry out a hardware benchmark test. But you never found anything suitable. I don't think my hardware isn't that bad.

or even that you never bothered to install the Oracle VirtualBox Extension pack

I actually have never heard of this. Is this part of the suggested components for VVV? If so, I'd be interested in trying it.

[tomjn]

I actually have never heard of this. Is this part of the suggested components for VVV? If so, I'd be interested in trying it.

it's hard not to have this if you've tried investigating things, opening VirtualBox' UI basically nags you to install it, but I'm not aware of any issues it might cause ( it's mostly for USB drive stuff and other more exotic things ), so it's basically me grasping at straws. I've helped setup plenty of machines at contributor days without seeing or mentioning it so I doubt it's related

In all honesty, I think the problem is that these plugins and themes are heavy, and it shows more in VVV than on enterprise grade server hardware. A quick look at the Avada theme site shows it has its own page builder and 101 options. By virtue of simply being itself it will never run as fast as a simpler theme such as the default ones.

There's a good chance the server at the other end is running a Xeon CPU with lots of cores and a silly amount of RAM, things you'd never find in consumer grade hardware. I like to think my maxed out MBP has decent CPU, but it doesn't hold a candle to some server hardware in benchmarks. Having said that I'm sure it demolishes them on GPU despite being an integrated chipset. With that in mind a clean install won't do much of anything

[cagross]

With that in mind a clean install won't do much of anything

The only reason I am trying this is re-build is because until now, I have been able to use VVV to efficiently build WordPress sites, on this same system. The sites I've built in the past haven't used Avada, or Wordfence. But they did use rather 'heavier' components (e.g. Visual Composer and WooCommerce). The last site I built with VVV was less than a year ago, and the site ran both Visual Composer and WooCommerce. There were none of these page load speed issues. So that's why I'm still holding out hope that this situation can be resolved, and I can get back to developing efficiently with VVV.

I think the problem is that these plugins and themes are heavy, and it shows more in VVV than on enterprise grade server hardware.

OK, could very well true. In this particular case, the remote server in-question is the lowest tiered shared hosting server from GoDaddy. So nearly bottom of the barrel in terms of delivered performance. I'm not sure on the exact server specs, but obviously each server will be more powerful than my lone computer. But does my site have access to the full resources of each server?

I'll try the Oracle VirtualBox Extension pack when I re-build VVV.

[tomjn]

OK, could very well true. In this particular case, the remote server in-question is the lowest tiered shared hosting server from GoDaddy. So nearly bottom of the barrel in terms of delivered performance. I'm not sure on the exact server specs, but obviously each server will be more powerful than my lone computer. But does my site have access to the full resources of each server?

It does, but everyone else has access to those same resources. Shared hosting isn't slow because it's on old machines, it's slow because they're shared. That's why you don't get object caching etc as it'd reduce the number of hosts that can run on a server. If nobody else visited the sites on that server you'd get dedicated server level performance, but the chances of that are 1 in a million.

Ideally you'd want a handful of powerful servers then load them up with as many sites as it can manage to get your moneys worth. The more low traffic sites that you can fit on it the greater the return. The same with VPS' only you can afford to fit fewer on them and move them to other machines if they run too hot. I'm sure my own digital ocean droplet is sharing a host with other VMs and that they've gambled that not all of them will spin up to full cpu usage at all times, but I know it's more secure than shared, more control, and that I can get more performance out of it if needs be, but the underlying hardware is probably identical

[cagross]

If nobody else visited the sites on that server you'd get dedicated server level performance,

Would I? Don't I have resource limits, e.g. 2 GB RAM, 1 MB/s bandwidth, etc?

[tomjn]

Would I? Don't I have resource limits, e.g. 2 GB RAM, 1 MB/s bandwidth, etc?

Those things get monitored, after all if you have 1000 sites on a host, but 90% of the resources are consumed by 1 busy site that has awful performance, then that sites owners likely to get told to reduce their CPU usage as they'll be slowing everybody else down to a crawl, possibly even booted off. Besides if your page requests require 2GB of RAM, or regularly take more than 15 seconds to generate, then something is terribly wrong. It's also why shared hosts make you agree not to use your account as a file download server.

Once you move to a VPS, you can throttle CPU availability and load balance properly, but shared hosts are kind of like the communal commons of old, which is why they're so cheap (and at times so slow). Managed hosting is more like a lightweight VPS except you only have control of the wp-content folder and limited host management

[cagross]

OK got it.

I'm working on the VVV re-install. I'll update you here on the results. It may take a few days though.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.