I am trying to create an application that runs on windows. I want this application to download a "disk image" from the network (from pre-assigned server) and create a virtual machine based on it. This VM would run for a specified number of hours and then shutdown.
I want to use VirtualBox by scripting it. I found VBoxManage command and it seems to be what I am looking for. However, it seems that VirtualBox tools store their configuration as XML files in User home directory. I did learn that i can change the value of VBOX_USER_HOME environment variable to control where they are stored. However, I am not sure whether this is enough.
My problem is that the user may already have installed VirtualBox on his/her computer. I do not want my application code (and it's packaged VirtualBox binaries and conf) to mess with the existing installation.
How do I cleanly isolate my application specific VirtualBox binaries and configuration from the potentially pre-existing installed VirtualBox setup? (Even if both instances of VirtualBox binaries are being used at the same time)
I chose VirtualBox because of it's open source license and applicability of commercial use (if I compile my own binaries from the source) and because it works on Windows too (heard QEMU support for windows is still not stable). Will VirtualBox suffice for my use-case or should I look elsewhere?
Thanks for reading so far :)
If the VBoxManage command really does rely on the environment variable VBOX_USER_HOME then you could write your scripts to change the environment variable to reflect your deployment for the execution of that script and its children, staying away from user data.
Check out the VirtualBox SDK http://download.virtualbox.org/virtualbox/SDKRef.pdf
Related
I'm writing a Windows application that interacts with a WSL distribution/instance which has Docker running. Also, in some cases, my application will also run commands/processes directly in the WSL/Linux distribution.
I would like for that WSL distribution to be "managed" by my application. By that, I mean that:
The distribution should be installed by my application so that users don't have to have knowledge of WSL itself. If the users have to install the WSL distribution themselves, it's entirely possible that they could misconfigure it. It's also possible that some users might not be able to get it up and running in the first place.
The user should have no control over my application's managed WSL distribution. They would not be able to:
Shutdown the instance when it is running under my application.
Uninstall the instance without uninstalling my application.
Preferably the user would not even see the distribution at all.
Can I create/install a distribution that is managed by my application in this way?
It's obvious that I could simply run a batch script, import the instance, and then just run it like that. But this seems verbose and, as mentioned, would still be visible to the end user.
Well, I definitely can't offer you a direct answer that meets those requirements, and I don't think it's possible, at least not currently.
WSL distributions are always visible to the end user. And they can always be --terminate'd or even --unregister'd. Even Docker Desktop's distribution are subject to these limitations.
You can see the Docker Desktop distros with wsl.exe -l -v, returning something like:
NAME STATE VERSION
* Tumbleweed Stopped 2
...
Ubuntu-22.04 Running 2
Artix-dinit Stopped 2
docker-desktop Stopped 2
docker-desktop-data Stopped 2
...
side-note: I have entirely too many distributions ;-)
But ... Docker Desktop does overwrite the distro with a new version when you upgrade, so any changes to it will (at least eventually) be overwritten.
So that does provide a possibility:
Ship your managed distro in tar form in/with your application.
When starting the application for the first time, create (--import) the distribution from the tarball.
Make sure that nothing in the distribution writes to/modifies the filesystem. You might could even set it read-only in some way, but I haven't tried that.
Perform a checksum of the distribution vhdx when starting each time, and confirm that it hasn't been modified.
If it has been modified, then delete it and re-import.
Alternatively, as mentioned in the comments, there may be a way to do this with a Hyper-V VM (but only, of course, on Windows Professional or higher). The WSL2 VM itself is hidden and managed in some way, and the same appears to be the case with BlueStacks.
I'm still not sure how they do this. From watching the Event Viewer, it appears that a new Hyper-V "Partition" is created when starting WSL2. This does not appear to be related to any "disk partitioning", so I believe that it is some type of Hyper-V partition that is hidden from the user.
I have tried installing latest versions of VirtualBox and Vagrant, but I keep receiving the error message below when trying to run vagrant. How can I find the problem and correct it?
No usable default provider could be found for your system.
Vagrant relies on interactions with 3rd party systems, known as
"providers", to provide Vagrant with resources to run development
environments. Examples are VirtualBox, VMware, Hyper-V.
The easiest solution to this message is to install VirtualBox, which
is available for free on all major platforms.
If you believe you already have a provider available, make sure it
is properly installed and configured. You can see more details about
why a particular provider isn't working by forcing usage with
`vagrant up --provider=PROVIDER`, which should give you a more specific
error message for that particular provider.
Be sure to install VirtualBox first, since Vagrant depends on it.
-Download and install VirtualBox
-Download and install Vagrant
-Adjust VirtualBox and Vagrant
The next step is to make some tweaks to VirtualBox and Vagrant. We need to do this because, by default, both tools store data in the same drive where they were installed (tipically the C drive). The thing with virtual machines is they can take up a lot of space, so they can eat up your main drive’s storage very quickly.
First we’ll change the storage path in Virtual Box, since it’s pretty straightforward. You now should have a program called Oracle VM VirtualBox installed. Open it and then go to File > Preferences. A
new dialog will open where you can change the folder next to the option that reads Default Machine Folder. Click the dropdown and choose Other…. Here you can choose the new folder for VirtualBox to store data.
Now we’ll do the same for Vagrant.
By default the path where data related to virtual machines is
stored is C:\Users\YourUser\.vagrant.d so I recommend changing it to a different drive. This can be done with environment variables. We need to create a variable called VAGRANT_HOME and point it to our desired location.
Open the control panel and search for the word environment. From the results choose the one that says edit environment variables for your account.
On the new dialog that appears, click the New… button.
Here you will create the new variable. Enter VAGRANT_HOME as the value for the field named Variable name.
For the field named Variable value enter the path of your choice. In my case I used C:\VM\Vagrant
I have a Vagrant set up with 3 virtual machines. Each machine has its own shell script for provisioning.
Now I would like to share the exact same status of my set up with somebody else. Since the provisioning procedure takes really (!!) long for each machine, I hope there is another solution.
Ideally I would be able to save each machine as it is in one file, which the other person then could import into Virtualbox. Is there a way to do that?
If I understand you correctly you would like to make a Vagrant base box from provisioned by Vagrant VMs. This is not recommended way to go. How you can approach this is:
Create new VM manually with required OS in the VBox.
Adjust it so Vagrant can connect to it as described here and here.
Provision it using your shell scripts.
Install all the things you would find useful to have on this VM.
Use Vagrant to package it as a base box as described here.
After packaging it with Vagrant you will get a Vagrant base box file with .box extension. You can then pass this to your team mates (usb, network share, ftp etc.) and they can add it to their Vagrant installation and use it. Whenever they will do Vagrant up they will get fully provisioned VM in VBox with all the stuff you have packaged to it. Vagrant also gives you versioning capabilities. If properly configured whenever you will create new version of base box everybody who is using it will be notified and would be able to download and use new version of your box.
Hope I understood your problem correctly and this will help to solve it.
I have program that I want to test on clean Windows installation. For now I have image in VirtualBox and I start program from shared folder, but this is not comfortable and I can't debug.
For debugging I found that I can use Remote Debugging Monitor, but still I want to automate whole process, especially uploading application on virtual machine.
I thought that VirtualPC would be better then VirtualBox, because this application was created by Microsoft. Unfortunately I can't find any info how to connect them.
EDIT:
After research: only possibility is to treat virtual machine as remote computer. There is no easier way. Project need to be published to VM using shared folders. After configuring in Visual Studion new release type for remote debugging all triggers automaticly and working.
I would:
1.Place the program in a pre-defined shared directory, such that it is immediately visible to the virtual machine after redeployment.
2.Remote debugger invokation can be automated - all the parameters, such as users allowed to debug can be passed on the command line.
VirtualBox is quite OK for this task, as it allows you to replace only the disk image with clean one, while leaving the setup, including shared directories intact. I am sure VirtualPC also allows such a thing, but choosing it just because it's also written by Microsoft does not seem like a valid consideration here.
I'm currently working on a server-side product which is a bit complex to deploy on a new server, which makes it an ideal candidate for testing out in a VM. We are already using Hudson as our CI system, and I would really like to be able to deploy a virtual machine image with the latest and greatest software as a build artifact.
So, how does one go about doing this exactly? What VM software is recommended for this purpose? How much scripting needs to be done to accomplish this? Are there any issues in particular when using Windows 2003 Server as the OS here?
Sorry to deny anyone an accepted answer here, but based on further research (thanks to your answers!), I've found a better solution and wanted to summarize what I've found.
First, both VirtualBox and VMWare Server are great products, and since both are free, each is worth evaluating. We've decided to go with VMWare Server, since it is a more established product and we can get support for it should we need. This is especially important since we are also considering distributing our software to clients as a VM instead of a special server installation, assuming that the overhead from the VMWare Player is not too high. Also, there is a VMWare scripting interface called VIX which one can use to directly install files to the VM without needing to install SSH or SFTP, which is a big advantage.
So our solution is basically as follows... first we create a "vanilla" VM image with OS, nothing else, and check it into the repository. Then, we write a script which acts as our installer, putting the artifacts created by Hudson on the VM. This script should have interfaces to copy files directly, over SFTP, and through VIX. This will allow us to continue distributing software directly on the target machine, or through a VM of our choice. This resulting image is then compressed and distributed as an artifact of the CI server.
Regardless of the VM software (I can recommend VirtualBox, too) I think you are looking at the following scenario:
Build is done
CI launches virtual machine (or it is always running)
CI uses scp/sftp to upload build into VM over the network
CI uses the ssh (if available on target OS running in VM) or other remote command execution facility to trigger installation in the VM environment
VMWare Server is free and a very stable product. It also gives you the ability to create snapshots of the VM slice and rollback to previous version of your virtual machine when needed. It will run fine on Win 2003.
In terms of provisioning new VM slices for your builds, you can simply copy and past the folder that contains the VMWare files, change the SID and IP of the new VM and you have a new machine. Takes 15 minutes depending on the size of your VM slice. No scripting required.
If you use VirtualBox, you'll want to look into running it headless, since it'll be on your server. Normally, VirtualBox runs as a desktop app, but it's possible to start VMs from the commandline and access the virtual machine over RDP.
VBoxManage startvm "Windows 2003 Server" -type vrdp
We are using Jenkins + Vagrant + Chef for this scenario.
So you can do the following process:
Version control your VM environment using vagrant provisioning scripts (Chef or Puppet)
Build your system using Jenkins/Hudson
Run your Vagrant script to fetch the last stable release from CI output
Save the VM state to reuse in future.
Reference:
vagrantup.com
I'd recommend VirtualBox. It is free and has a well-defined programming interface, although I haven't personally used it in automated build situations.
Choosing VMWare is currently NOT a bad choice.
However,
Just like VMWare gives support for VMWare server, SUN gives support for VirtualBOX.
You can also accomplish this task using VMWare Studio, which is also free.
The basic workflow is this:
1. Create an XML file that describes your virtual machine
2. Use studio to create the shell.
3. Use VMWare server to provision the virtual machine.