I'm pretty new to both VirtualBox and Vagrant, but not Jenkins. I have a Jenkins build being run on a Windows slave that is running "vagrant up" in a specific directory. There was a problem with the VM- I went to that directory and tried to manually run vagrant up and it started recloning the box. Investigating, the VirtualBox VMs folder is being stored in /Windows/system32... I have looked and the Jenkins process and the VirtualBox process are definately being run as the user account that is running the jenkins slave. If I log into that account and launch virtualbox, it looks for VMs in the account home directory though!
I could probably fix this by pointing both accounts to a third location, but I would like to understand why this is happening. Any takers?
According to the docs, since VirtualBox 4.0, the default location where virtual machines are saved is the current system user's home directory. So:
C:\Documents and Settings\<username> on Windows
/Users/<username> on Mac OS X
/home/<username> on Linux and Solaris
Take a look at the Default Machine Folder settings of the virtualbox on your Windows slave to see if anyone has changed the path to /Windows/System32
File > Preferences > General > Default Machine Folder
Also, I am assuming you are using the jenkins vagrant plugin to spawn your vagrant box? (If not, you should). AFAIK, that plugin doesn't require any system administrator privilege on the slave machine.
Related
VirtualBox 6.1.28 fails to start a box on Windows with the following error:
Failed to load R0 module C:\Program Files\Oracle\VirtualBox/VMMR0.r0:
SUP_IOCTL_LDR_OPEN failed (VERR_LDR_GENERAL_FAILURE).
Failed to load VMMR0.r0 (VERR_LDR_GENERAL_FAILURE).
VirtualBox v. 6.1.28 is buggy, use another version (e.g. 6.1.26 or 6.1.32) which you can download from https://www.virtualbox.org/wiki/Download_Old_Builds_6_1
The issue is tracked as https://www.virtualbox.org/ticket/20694 and was fixed in v. 6.1.32.
A workaround...
https://www.virtualbox.org/ticket/20694
"The Windows Hypervisor-enforced Code Integrity (HVCI) feature rejects the VirtualBox component VMMR0.r0 (*). A workaround is to disable HVCI aka Memory integrity as follows:
On your Windows host, go to Start > Settings > Update & security > Windows Security > Device security > Core isolation details, turn off Memory integrity and reboot the Windows host.
(*) In the Windows Event Log, under Applications and Service Logs\Microsoft\Windows\CodeIntegrity\Operational, an event with ID 3111 ("The file under validation did not meet the hypervisor-protected code integrity (HVCI) policy.") is logged."
Fixed moving to 6.1.26
On Windows 10:
Uninstall VirtualBox using the control panel "Program and functionalities" tool. DO NOT RESTART YET.
Manually check for the following folders and remove them if they are still there:
C:\Program Files\Oracle\VirtualBox
C:\Program Files (x86)\Oracle\VirtualBox
Note: The folders can be in a different place depending where you installed Oracle VirtualBox; make sure to check the correct folder in case you changed the installation directory.
Go to your %userprofile% directory (eg: C:\users\me) and delete the folders:
.VirtualBox
VirtualBox VMs
Go to RegEdit (WIN+R and type regedit) and click on Computer at the very top.
Then click on "Edit" > "Search" or hit CTRL+F. Type virtualbox and tick all checkboxes.
Find the key Oracle > VirtualBox. It should be in
Computer\HKEY_CURRENT_USER\SOFTWARE\Oracle\VirtualBox
Remove the VirtualBox key.
IMPORTANT: RESTART NOW. Restart your computer!
Install VirtualBox again with the new version.
Thanks to: https://forums.virtualbox.org/viewtopic.php?t=82689
I had the same problem and found a solution. You have to open Oracle VM VirtualBox.exe and move into your machine settings, make sure that in Controller: SATA you have only .iso of your machine, if you have something else, delete it, close Oracle VM VirtualBox. In Control panel find programs and features, delete your Oracle VM VirtualBox. Then download Oracle VM VirtualBox again, it's not necessary, which version you will launch but better the latest or the same you had before. After installation check out a capability of your machine, if it works, you may add other .iso back, if it doesn't work, open settings again and Controller: SATA delete all .iso exclude your machine .iso, then launch the machine again.
It works with my virtual machines, if it's not relevant to your occasion, you can try other variants.
I have a very strange problem with Cygwin sshd and changing the PATH environment variable through the Windows control panel. This is with Windows 10 64 running in a Parallels VM
After a reboot ssh sessions into the Windows machine will still use the old path. Local Cygwin sessions have no such problem: they will use the new path.
Note the bold text: I am aware that without the reboot this is expected to happen (because sshd got started with the old environment). But the After the reboot has got me baffled. If I ssh into the machine I see the old PATH. If I then reboot the VM again and ssh in again I finally see the new path.
Incidentally (fodder for future people googling this) I had the problem while using gitlab-runner to run CI/CD jobs on Windows using Parallels VMs on my Mac. So I would prepare the VM to have all the right tools installed and everything set correctly, then shut it down. gitlab-runner will then clone the VM and run the CI/CD jobs on it. Works now, as long as I reboot the original VM twice with an ssh session in between before having it cloned by gitlab-runner:-)
I never posted the answer I found: the problem was that hibernate was enabled on Windows. Actually the first "restart" was usually a shutdown followed by a startup.
But, by default Win10 has hibernate enabled, and if that is the case a shutdown and startup don't actually reboot the OS.
Disabling hibernate fixed it.
Double-check your Cygwin sshd installation, as described in "Installing Cygwin and Starting the SSH Daemon"
it makes sure the %PATH% does not reference other SSH, like W10 OpenSSH.
it stops any other SSH service.
it defines a Cygwin SSH Windows service, using a local account, which then should pick up the same account new path after a single reboot (or even with restarting the service, without reboot)
I am not sure why you need two reboots in your case, but see if that Cygwin sshd setup works better.
Unable to run DockerToolbox1.11.2.exe in Windows7.
Tried running the installer using admin privileges, wont run. Task manager status shows not responding.
Could it be corporate proxy settings?
I have 64bit Windows7 laptop.
Verified Hardware assisted
virtualization is enabled on this computer
Try the alternative: docker machine v0.8.0-rc2
All you need to do is:
download docker-machine-Windows-x86_64.exe,
rename it in docker-machine.exe somewhere on your %PATH%,
type doskey dm=docker-machine.exe $*
then type 'dm' (that will display the help)
From there you can start creating docker machines.
I am running a vagrant VM on OSX. I have set up a synced folder for the VM in which I run react-native packager. When I edit files on my host computer, the packager does not automatically detect that the file has changed. This works if I edit the file directly in the VM. I have checked that the file actually changes on the VM when I edit it on my host computer. Has anybody had the same problem or figured out a solution how to get this working?
I have been able to setup Vagrant on Windows 7 64-bit for a django project. The Vagrant instance is running the application with postgres as backend. I have setup port forwarding, so I am able to access through my browser on local machine. I have also setup remote interpreter in PyCharm. But, I am unable to figure out how to open the project, which is on vagrant instance, in PyCharm 3.0. I also have the source code on my local machine.
Any ideas?
Thanks
Synced Folders may be something you are looking for.
NOTE: by default Vagrant use VirtualBox's vboxsf for synced folder and share your project directory (where the Vagrantfile resides) to /vagrant within the guest.
However, vboxsf has known performance issues with large number of files and directories. You can try to move the project to /vagrant (or whatever synced folder) so that both the host (Windows 7) and guest can access the project easily. See if it works well. If you see slowness try moving to NFS or sshfs.
Reference
Vagrant shared and synced folders
What is the difference between shared folder and synced folder in Vagrant?