@Alvaro - regarding the 2 expensive virtualizers, please see the details earlier in this thread (it is not the desired end state).
We have been targeting VirtualBox with our users & box files, although we're not using provider specific configuration in our Vagrantfile. Is there a simple way to set LXC as the provider / default virtualizer and try starting my Vagrant VM with LXC? I'm not a Linux guru, but if it's as simple as installing a few packages and modifying some configuration files, I'm certainly willing to try LXC. - Brian On Sun, May 11, 2014 at 7:03 PM, Alvaro Miranda Aguilera <[email protected]>wrote: > Can I ask why you are suing 2 expensive virtualizations? the performance > should not be a surprise here. > > Why you need Virtualbox running inside vmware on the firstplace? > > Are other virtualization that are light, like LXC or Docker that should > run faster/better. > > Other may be XEN or KVM, but basically a good understanding on "what you > need" will be helpful to be able to suggest "how I should do it" if I have > to do the same as you want.. > > > > On Mon, May 12, 2014 at 9:48 AM, Brian Long <[email protected]> wrote: > >> Thanks Mitchell, I've done that (see the attached screenshot), but still >> the performance seems really bad. The reason for double-virtualization >> at this point is to build out the CentOS host that can then be exported and >> moved to a vShpere environment. Once I'm sure the CentOS host is configured >> properly, it'll be moved to the server hypervisor and no longer be run it >> in VMWare Fusion. My strategy was to configure and check the CentOS host >> before exporting it, but maybe I'd be better off moving to vSphere first? >> >> >> >> >> On Sun, May 11, 2014 at 5:36 PM, Mitchell Hashimoto < >> [email protected]> wrote: >> >>> Brian, >>> >>> Make sure you check the box (or enable the setting) to enable >>> virtualization extensions inside the VM. It is not on by default. >>> >>> Best, >>> Mitchel >>> >>> On Sun, May 11, 2014 at 2:30 PM, Brian Long <[email protected]> >>> wrote: >>> > Mitchell, >>> > Sorry, I should have clarified, I'm not running VirtualBox inside >>> > VirtualBox. I'm running VirtualBox inside VMWare Fusion. Do you think >>> > throwing more memory (e.g. 10 GB?) at it will help? I'm a bit >>> desperate at >>> > this point :) We really like Vagrant and want to build out an >>> environment >>> > for testing new builds. >>> > >>> > - Brian >>> > >>> > >>> > On Sun, May 11, 2014 at 5:25 PM, Mitchell Hashimoto >>> > <[email protected]> wrote: >>> >> >>> >> Brian, >>> >> >>> >> VirtualBox doesn't support running in VirtualBox. You can run >>> >> VirtualBox in another VM (VMware) usually, but it is very expensive. >>> >> >>> >> Best, >>> >> Mitchell >>> >> >>> >> On Sun, May 11, 2014 at 2:23 PM, Brian Long <[email protected]> >>> wrote: >>> >> > Is there a trick to getting VirtualBox to run smoothly inside a >>> linux >>> >> > VM? >>> >> > I've followed a few different tutorials for installing VirtualBox in >>> >> > CentOS, >>> >> > which typically include installing DKMS, kernel-devel & >>> kernel-headers. >>> >> > The >>> >> > latest advice I saw indicated that IPv6 networking might be the >>> slowness >>> >> > culprit, but even with that disabled my VMs still run slowly. Any >>> >> > tutorials, pointers or even someone's bash history would be greatly >>> >> > appreciated :) >>> >> > >>> >> > On May 9, 2014 3:27 PM, "blong" <[email protected]> wrote: >>> >> >> >>> >> >> Mitchell, >>> >> >> Thanks for getting back to me so quickly & thanks for the info. I >>> am >>> >> >> trying to run VirtualBox inside VMWare Fusion. Later on, the goal >>> is >>> >> >> to >>> >> >> move the VMWare fusions instance to VCenter. I'm not sure if it's >>> >> >> helpful, >>> >> >> but my "VAGRANT_LOG=debug" output is attached. >>> >> >> >>> >> >> Thanks, >>> >> >> Brian >>> >> >> >>> >> >> On Friday, May 9, 2014 3:16:57 PM UTC-4, Mitchell Hashimoto wrote: >>> >> >>> >>> >> >>> VirtualBox itself doesn't support VirtualBox running in >>> VirtualBox. >>> >> >>> >>> >> >>> VMware this works fine. >>> >> >>> >>> >> >>> On Fri, May 9, 2014 at 11:56 AM, blong <[email protected]> >>> wrote: >>> >> >>> > I'm assuming this isn't recommended, but stay with me! I'm >>> trying >>> >> >>> > to >>> >> >>> > configure a CentOS environment to run VirtualBox and Vagrant >>> without >>> >> >>> > any >>> >> >>> > issues. A while back, I was able to successfully nest the >>> >> >>> > "hashicorp/precise32" VM running in VirtualBox within another >>> >> >>> > "hashicorp/precise32" VM running in VirtualBox (as long as >>> >> >>> > VT-x/AMD-V >>> >> >>> > is >>> >> >>> > enabled). It's been so long, that I can't exactly remember, >>> but I >>> >> >>> > might >>> >> >>> > have been running CentOS inside the precise32 VM, or vice-versa. >>> >> >>> > >>> >> >>> > I've installed both VirtualBox and Vagrant in CentOS (multiple >>> >> >>> > experiments >>> >> >>> > using various versions of each), but no matter what I do my >>> inner VM >>> >> >>> > runs >>> >> >>> > slowly. I don't expect this, since I gave the CentOS VM more >>> than >>> >> >>> > 7GB >>> >> >>> > of >>> >> >>> > memory, and 2 cores from a 2.7GHz Core i7 (real hardware). When >>> I >>> >> >>> > try >>> >> >>> > to >>> >> >>> > startup my inner VM's (with or without Vagrant) they run >>> slowly, and >>> >> >>> > don't >>> >> >>> > seem to allocate much memory. As the VM is booting, I see CPU 1 >>> & 2 >>> >> >>> > spike a >>> >> >>> > bit, then eventually drop, but the total memory usage by CentOS >>> >> >>> > doesn't >>> >> >>> > rise >>> >> >>> > above 1GB (via CentOS' System Monitor). When trying to start the >>> >> >>> > "precise32" >>> >> >>> > VM, it times out like this: >>> >> >>> > >>> >> >>> > [me@localhost hashicorp-precise32]$ vagrant destroy >>> >> >>> > default: Are you sure you want to destroy the 'default' VM? >>> >> >>> > [y/N] y >>> >> >>> > ==> default: Destroying VM and associated drives... >>> >> >>> > [me@localhost hashicorp-precise32]$ vagrant up >>> >> >>> > Bringing machine 'default' up with 'virtualbox' provider... >>> >> >>> > ==> default: Importing base box 'hashicorp/precise32'... >>> >> >>> > ==> default: Matching MAC address for NAT networking... >>> >> >>> > ==> default: Checking if box 'hashicorp/precise32' is up to >>> date... >>> >> >>> > ==> default: Setting the name of the VM: >>> >> >>> > hashicorp-precise32_default_1399644995759_24359 >>> >> >>> > ==> default: Clearing any previously set network interfaces... >>> >> >>> > ==> default: Preparing network interfaces based on >>> configuration... >>> >> >>> > default: Adapter 1: nat >>> >> >>> > ==> default: Forwarding ports... >>> >> >>> > default: 22 => 2222 (adapter 1) >>> >> >>> > ==> default: Booting VM... >>> >> >>> > ==> default: Waiting for machine to boot. This may take a few >>> >> >>> > minutes... >>> >> >>> > default: SSH address: 127.0.0.1:2222 >>> >> >>> > default: SSH username: vagrant >>> >> >>> > default: SSH auth method: private key >>> >> >>> > default: Warning: Connection timeout. Retrying... >>> >> >>> > default: Warning: Connection timeout. Retrying... >>> >> >>> > default: Warning: Connection timeout. Retrying... >>> >> >>> > >>> >> >>> > ... # Omitted for brevity >>> >> >>> > >>> >> >>> > default: Warning: Connection timeout. Retrying... >>> >> >>> > Timed out while waiting for the machine to boot. This means that >>> >> >>> > Vagrant was unable to communicate with the guest machine within >>> >> >>> > the configured ("config.vm.boot_timeout" value) time period. >>> >> >>> > >>> >> >>> > If you look above, you should be able to see the error(s) that >>> >> >>> > Vagrant had when attempting to connect to the machine. These >>> errors >>> >> >>> > are usually good hints as to what may be wrong. >>> >> >>> > >>> >> >>> > If you're using a custom box, make sure that networking is >>> properly >>> >> >>> > working and you're able to connect to the machine. It is a >>> common >>> >> >>> > problem that networking isn't setup properly in these boxes. >>> >> >>> > Verify that authentication configurations are also setup >>> properly, >>> >> >>> > as well. >>> >> >>> > >>> >> >>> > If the box appears to be booting properly, you may want to >>> increase >>> >> >>> > the timeout ("config.vm.boot_timeout") value. >>> >> >>> > >>> >> >>> > >>> >> >>> > I posted a comment on StackOverflow about this, but I'm not >>> sure if >>> >> >>> > that >>> >> >>> > will drum up a response from the guy who appears to have had >>> success >>> >> >>> > with a >>> >> >>> > nested VM arrangement: >>> >> >>> > >>> >> >>> > >>> >> >>> > >>> http://stackoverflow.com/questions/17175696/running-vagrant-inside-vmware-vm/22931930#comment36172153_22931930 >>> >> >>> > >>> >> >>> > Would anyone be able to help me get this working? >>> >> >>> > >>> >> >>> > Thanks in advance! >>> >> >>> > >>> >> >>> > -- >>> >> >>> > You received this message because you are subscribed to the >>> Google >>> >> >>> > Groups >>> >> >>> > "Vagrant" group. >>> >> >>> > To unsubscribe from this group and stop receiving emails from >>> it, >>> >> >>> > send >>> >> >>> > an >>> >> >>> > email to [email protected]. >>> >> >>> > For more options, visit https://groups.google.com/d/optout. >>> >> >> >>> >> >> -- >>> >> >> You received this message because you are subscribed to a topic in >>> the >>> >> >> Google Groups "Vagrant" group. >>> >> >> To unsubscribe from this topic, visit >>> >> >> >>> https://groups.google.com/d/topic/vagrant-up/6YHdRupCKuI/unsubscribe. >>> >> >> To unsubscribe from this group and all its topics, send an email to >>> >> >> [email protected]. >>> >> >> >>> >> >> For more options, visit https://groups.google.com/d/optout. >>> >> > >>> >> > -- >>> >> > You received this message because you are subscribed to the Google >>> >> > Groups >>> >> > "Vagrant" group. >>> >> > To unsubscribe from this group and stop receiving emails from it, >>> send >>> >> > an >>> >> > email to [email protected]. >>> >> > For more options, visit https://groups.google.com/d/optout. >>> >> >>> >> -- >>> >> You received this message because you are subscribed to a topic in the >>> >> Google Groups "Vagrant" group. >>> >> To unsubscribe from this topic, visit >>> >> https://groups.google.com/d/topic/vagrant-up/6YHdRupCKuI/unsubscribe. >>> >> To unsubscribe from this group and all its topics, send an email to >>> >> [email protected]. >>> >> For more options, visit https://groups.google.com/d/optout. >>> > >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> Groups >>> > "Vagrant" group. >>> > To unsubscribe from this group and stop receiving emails from it, send >>> an >>> > email to [email protected]. >>> > For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "Vagrant" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/vagrant-up/6YHdRupCKuI/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Vagrant" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Vagrant" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/vagrant-up/6YHdRupCKuI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Vagrant" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
