When I installed Windows XP on a VirtualBox machine, I made the hard drive only 10 GB since and assumed it would expand in size (as do hard drives in VMWare as far as I can remember, isn't this true?).
In any case, I'm trying to install Visual Studio 2010 beta on this Virtual Box XP image and it has run out of disk space.
Googling for an answer, I'm finding complicated tutorials like this which show you how to increase the size of a VirtualBox hard drive "in just a couple hours".
But I can't imagine it would be that hard to either:
increase the size of a virtual disk (after all, it is virtual)
create a new hard drive of, say, 20 GB and just attach it in the virtual machine as the D: or E: drive
How can I easily add storage space to a VirtualBox machine with XP installed?
I found this nugget at the link following. It worked perfect for me and only took 5 seconds.
As of VirtualBox 4 they added support for expansion.
VBoxManage modifyhd filename.vdi --resize 46080
That will resize a virtual disk image to 45GB.
https://superuser.com/questions/172651/increasing-disk-space-on-virtualbox
Note: This applies to pre-4 VirtualBox. In VB4, HDD expansion has been introduced.
According to the VirtualBox documentation:
When creating an image, its size needs to be specified,
which determines this fixed geometry. It is therefore not possible to change the size of
the virtual hard disk later.
So, the easiest way to add additional space to an existing VM is to attach a second hard disk. Go to the VM Settings > Hard Disks > Add New. Then, click the "Select Hard Drive" button and click on "New". Follow the wizard to create a new virtual hard disk. It will then show up as D: or E: in your guest OS.
For Windows users there's an additional user friendly option: CloneVDI Tool by mpack. It's a GUI front-end to VBoxManage that makes things a little easier to work with.
http://forums.virtualbox.org/viewtopic.php?f=6&t=22422
As Alexander M. mentioned, you'll still have to use GParted, Partition Magic or a similar partition editor to grow your partition to the newly allocated physical drive. To do this just download the GParted iso, mount it as a bootable drive in the VirtualBox and boot from it.
http://gparted.sourceforge.net/download.php
Newer versions of VirtualBox add an option for VBoxManage clonehd that allows you to clone to an existing (larger) virtual disk.
The process is detailed here: Expanding VirtualBox Dynamic VDIs
Step 1 :
create new virtual disk as per #mhaller instruction
Step 2 :
Open Run dialog box type diskmgmt.msc and enter
Step 3 :
Select uninitialized partition, right click->initialize
Step 4 :
Select the partition again, right click and create extended partition, again right click create logical drive (adjust the partition size if you need in wizard)
Thats all
For windows users:
cd “C:\Program Files\Oracle\VirtualBox”
VBoxManage modifyhd “C:\Users\Chris\VirtualBox VMs\Windows 7\Windows 7.vdi” --resize 81920
http://www.howtogeek.com/124622/how-to-enlarge-a-virtual-machines-disk-in-virtualbox-or-vmware/
Take a look at CloneVDI from the VirtualBox site... 100% painless!
I am glad you were able to get this done in this manner, but you can (and I did) use the GParted tool for my Windows XP host by following the helpful entry by Eric. To re-iterate/expand on his solution (don't be afraid of the # steps, I'm trying to help newbies here, so there are necessarily more detailed instructions!):
change the size of the virtual hard disk via the VBoxManage modifyhd command, which is well-documented here and in the VirtualBox documentation.
download the GParted-live (http://sourceforge.net/projects/gparted/files/latest/download?source=dlp) or search the internet for GParted-live ISO. The important part is to get the live (.iso) verison, which is in the form of a bootable .ISO (CD) image.
Mount this new .ISO to the CD virtual drive in the host machine's Storage settings
If necessary/desired, change the boot order in the System settings for the host machine, to boot from CD before Hard Disk (alternatively, you can press F12 when it's booting up, and select the device)
start your VM; if you changed the boot order, it will boot to the GParted-live ISO; otherwise press F12 to do this.
do not be afraid or get too confused/wrapped up in the initial options you are presented; I selected all the defaults (booting to GParted default, default key mapping, language (assuming English - sorry for my non-English friends!), display, etc.). Read it, but just press enter at each prompt. With a Windows VM you should be fine with all the defaults, and if you're not, you're not going to break anything, and the instructions are pretty good about what to do if the defaults don't work.
it will boot to a GUI environment and start the GParted utility. Highlight the c: drive (assuming that's the drive you want to increase the size on) and select resize/move.
change to the new size you want in MB (they abbreviate MiB) - just add the new amount available (represented in the bottom number - MiB following) to the middle number. E.g: I changed mine from like 4000 MiB (e.g., 4GB - my initial size) to 15000 MiB (15 GB) because I'd added 10 GB to my virtual disk. Then click OK.
Click Apply. Once it's done you'll have to reboot - for whatever reason my mouse did not work on the desktop icons on the GUI (I could not click exit) so I just closed the VM window and selected reboot. I did not even have to unmount the ISO, it apparently did it automatically.
Let Windows go through the disk check - remember, you just changed the size outside of Windows, so it has no record of this. This will presumably allow it to update itself with the new info. Once it completes and you log in, you'll likely be told that Windows needs to reboot to use your 'new device' (at least in XP it did for me). Just reboot and you are done!
These steps worked for me to increase the space on my windows VM:
Clone the current VM and select "Full Clone" when prompted:
Resize the VDI:
VBoxManage modifyhd Cloned.vdi --resize 45000
Run your cloned VM, go to Disk Management and extend the volume.
Adding a second drive is probably easiest. That would only take a few minutes, and it wouldn't require any configuration, really.
Alternatively, you could create the second, bigger drive, then run a disk imaging utility to copy all data on disk1 to disk2. That certainly shouldn't take a few hours, but it would take longer than just living with two drives.
i used following instructions, its so easy to increase virtual box disk size
http://blog.bhupen.me/1/post/2011/09/increase-virtualbox-disk-size.html
The problem is that the file system on that disk was created when the disk had a certain geometry and you must modify it (while your OS is running on it).
So yes, making the virtual hard disk bigger is not a big issue. The issue is to make the new space available to your OS. To do that, you need tools like parted (Linux) or Partition Magic (Windows).
Taked from here => forums.virtualbox.org/viewtopic.php?p=41118#p41118
You could try something like this (see also Tutorial - All about VDIs: How can I resize the partitions inside my VDI?):
Create a new VDI of the desired size.
Boot GParted Live in a VM with both old and new VDIs attached.
Check in the partition editor (opened automatically after booting) what your old and new disk locations are. (It'll be something like /dev/hda and /dev/hdb.)
Copy contents from old to new disk. This will take a fair amount of time. (Here /dev/hdX is your original disk and /dev/hdY the new one).
dd if=/dev/hdX of=/dev/hdY
Warning: Make sure you do not mix up your input and output disks or you'll wipe all information from your original disk! (if= specifies the input and of= specifies the output.)
Reboot (again with GParted-Live). Now you should be able to increase the Windows partition size on the new disk.
Once you've verified the larger VDI boots Windows fine (and disk size is as you'd expect) you can of course delete the old smaller VDI.
Edit: Instead of rebooting before you resize the partition you should be able to run partprobe and the hit CTRL+R in GParted instead.
After resizing and not being able to view the resizing on my windows XP guest machine, I had to
clone it
resize it with
"VBoxManage modifyhd winxppro\ Clone.vdi --resize 30720"
and everything worked
I saw in other forums that snapshots can interfere for resizing and not being able to remove all snapshots for different errors I got, the only found solution for me was to clone it to remove the snapshots and then resize it, and everything worked. For resizing outside windows, a gparted boot cd that can be found here can help
If you want to resize a fixed size disk, or want to USE the resized disk
VBoxManage modifyhd filename.vdi --resize 99999
won't work. It supports only dynamic disks. Even for a dynamic disk, you'll have to resize the partitions.
Make a backup copy of your VM.
you have to go to VirtualBox manager, File-VirtualMediaManager.
There copy your virtual disk to another one. Make it dynamic while copying.
Go to your machine, Settings - Storage. Link to the new disk.
Return to VirtualMediaManager. Release the old disk.
NOW make resize with the new disk, as
VBoxManage modifyhd filename.vdi --resize 99999.
Resize partitions on the new disk:
download live Linux or live GParted iso.
In VirtualBox manager - settings - Storage - CD's add this iso.
VirtualBox manager - settings - system set loading from CD
launch VM, launch sudo gparted.
right click swap partition, UNSWAP it.
Move right border of the extended partition with swap up to the right.
Move swap to the right
Move left border of the extended partition up to the right
Move right border of YOUR partition up to the right.
Close VM
Remove CD from VM
check how it works
Close VM
remove the old disk in VirtualMediaManager.
Here you are!
Related
Host machine: Debian 10 running NoMachine 7.2.3
Settings:
Specified H264
User Hardware Encoding enabled
Use Specific Frame Rate enabled (60FPS)
Use Acceleration enabled
Client: Windows 10 running NoMachine 7.2.3
Both machines have monitors attached.
Using NX protocol for connection.
FullScreen / Scale to Window / Desktop is currently 2560x1440 (reduced from native while testing this issue)
Specific issue:
I do a ton of work in the terminal and when viewing desktop via nomachine, the terminal caret is randomly not visible. The same issue is less noticeable with right click menus and other areas of "visual updates in small screen space." If this were another remote desktop vendor I would try to find the "don't update just regions" setting to force the entire display to update regularly, but I can't find similar settings for nomachine. I have a dedicated gigabit connection between the two machines with no other traffic on that line, so bandwidth is not an issue.
To recreate:
I disabled caret blink (using universal access / accessibility settings) so the caret is a solid block in terminal / vi. If I edit a text file in vi and move up and down, the caret will only update visually every other line or so (verified on the physical screen it is moving correctly). Same if I highlight or insert, etc. You inevitably miss a character or so or lose your place).
I have tried changing speed vs quality slider, resolutions, swapping from h264 to VP8, etc.
I have disabled:
multi-pass display encoding
frame buffering on decoding
client side image post-processing
Nothing seems to change this specific issue. Yes I can make dragging a quarter-screen-sized terminal window smoother, but that doesn't help me follow the caret in vi/vim. Both machines are nicely spec'd (client has 16G / RTX2080, server has 32G / GTX1080)
Is there a way to get nomachine to update all the screen all the time, or at least better refresh small areas like a terminal caret?
(OP): Based on a night of troubleshooting, the issue seemed to be either:
An issue with the Debian install of the nvidia drivers
The server machine is a laptop with a broken main screen (but with an HDMI external monitor plugged in). The Debian X-server may have been confused as to whether it was headless or not and caused issues with nomachine (which tries to detect headless and start a virtual session).
The solution to this exact problem would be to disable the GUI and force a virtual session, per https://www.nomachine.com/AR03P00973 (dummy dongles won't work because the laptop's main display is not a standard plug).
In my specific case, I needed GUI access on the server at times so I couldn't use the above methods, and I could not remedy the problem with Debian, so I wiped the system and installed Ubuntu 20.04, which is more forgiving with graphics drivers and monitors. After setting up the Ubuntu system as similarly as possible to the Debian system and letting the proprietary nvidia drivers auto install, nomachine connected at the same resolution and worked perfectly, without the lag in small screen areas.
I am using Docker for Windows last version.
Before a week I had an update which asked me if I want to switch between HYPER-V to WSL if I remember correctly.
Swapped it and everything worked well as it should be, today I added a ram (same ram as I had, corsair vengeance 2x8gb 3200mhz ddr4).
but everything works good. I have 32 gigabyte now so I wanted to change the limit I gave to docker which was 6/16 cores and 6/16 ram. wanted to switch it up for like 12/32 ram so I was searching for the advanced setting which I used to limit the ram and cores before and I didn't manage to find it.
seems like the option just disappear.
I have to give docker more ram because I want him to run 2 programs at the same time which take more than 6gb ram.
what I have and what did I try conclusion :
I'm using windows.
I have 32 gigabyte ram.
I tried to reinstall docker.
I tried to remove the image and containers and add them again.
still did not find the setting which I used before which is really annoying.
any ideas ?
apparently using WSL based engine removes the option "advanced" so Currently using hyper-v instead of wsl solved my problem.
thanks anyway
We have developed a tool in python which uses many libraries and other algorithms. We want to give that to customers on premise through docker image. It works pretty well. However, if someone copies image and exports/extracts (export or save command), everything becomes visible that includes our python files and library (python) files as well.
Is there a way, we can protect our code such that customers can't export it or see anything inside the image? Is there a way whole image can be encrypted or locked? I believe obfuscation can help to an extent, is there an obfuscation tool that obfuscates whole project (all files and folders while not breaking references)?
The root user on the host machine (where the docker daemon runs) has full access to all the processes running on the host. That means the person who controls the host machine can always get access to the RAM of the application as well as the file system. That makes it impossible to hide a key for decrypting the file system or protecting RAM from debugging.
Since you are sharing the image, You got no way to protect it from copying.
However using obfuscation on a standard Linux box, you can make it harder to read the file system and RAM, but you can't make it impossible or the container cannot run.
I am trying to learn Docker and for that referring to online materials. I came to know that there is official hub of images which we can pull, and run a container.
The repos are available at https://hub.docker.com/ , part of screen shot:
In this diagram we can see the official images of ubuntu, httpd, mysql (and so on).
My question is:
Do all these images have "minimal OS" on which they run. For example, if we consider httpd image, does it have the needed OS on which it runs?
From my understanding images are built in a layered architecture from a parent image. So we have a parent image and then the changes for this image is one more layer above parent image. If you see dockerfile for an image you can see something like this
FROM node:6.11.5
This node:6.11.5 is a parent image for our current image.
If you check dockerfile of parent images you will find they are somewhere in the hierarchy follow from base image.
This base image is basically an OS without kernel but has only userland software based on the different linux distributions(eg, centos, debian). So all the images uses the host OS kernel. Hence, you cannot install a Windows container on a Linux host or vice-versa.
So basically all images are layered changes on the base image which is an OS without kernel.
Please find below links for further information:
https://serverfault.com/questions/755607/why-do-we-use-a-os-base-image-with-docker-if-containers-have-no-guest-os
https://blog.risingstack.com/operating-system-containers-vs-application-containers/
If you need to create a base image you can see the steps here.
https://docs.docker.com/develop/develop-images/baseimages/
Please correct me if i am wrong.
Here's the answer: "Containers," in all their many forms, are an illusion!"
Every process that is "running in a container" is, in fact, running directly on the host operating system. But it is "wearing rose-colored glasses." It thinks that it knows what its user-id is ... but it doesn't. 🤷♂️ It thinks it knows what the network looks like. What the filesystem looks like. ... ... ...
And, it can afford to think that way, because nothing that it is able to see would tell it otherwise.
... But, nothing that it sees is actually the physical truth.
"Containerization" allows us to achieve the essential technical requirement – total isolation – at very-considerably less cost than "virtualization." The running processes see what they need to see, and so "they need be none the wiser." Meanwhile, the host operating system, which is aware of the actual truth, can very-efficiently support them: it just has to maintain the illusion. The very-expensive "virtual machine" software layer is completely gone. The only "OS" that actually exists is the host.
Most images are based on a distribution as you can see it in their Dockerfiles. Except for the distribution images themselves. They have a different base-image, which is called scratch.
You can review the images they are based on when you visit the project's page on DockerHub, for example https://hub.docker.com/_/httpd/
Their Dockerfiles are referenced and you can review them by clicking on them, e.g. the first tag "2.2" refers to this file. The first line in the Dockerfile is FROM debian:jessie and shows, that it is based on a Debian image.
It is widely used to have a separated tag with the postfix -alpine in it to indicate, that alpine linux is used, which is a much smaller base-image than the Debian image. This leads to a smaller image of the httpd image, because the base-image is much smaller.
The whole idea is that the whole image is completely stand-alone running on hardware/virtualization layer. And thus (the pro:) also cannot be influenced by anything else than that is part of the image.
Every image contains an complete os. Special docker made OS's come with a few mega bytes: for example linux Alpine which is an OS with 8 megabytes!
But bigger OS like ubuntu/windows can be a few gigabytes. Both have their advantages since docker cuts an image up in layers so when you use anbase image twice (FROM command, see N20 Answers) then you will only download this layer once.
Smaller OS has the pro of only needing to download a few megabytes. but for every (linux) Library you want to use, you will have to download & include yourself. This custom made layer then is only used in your own image and thus is not re-used in other images and thus creates a customer extra download layer & megabytes people will have to download to run your image.
If you want to make an image from nothing you can start your dockerfile with:
FROM scratch
But this is not advised, unless you really know what your are doing and/or you are hobbying around.
I think a lot of these answers miss the point. Explaining what you can or may do does not answer the question: do all docker images need an OS?
After a bit of digging, the answer is no.
https://docs.docker.com/develop/develop-images/baseimages/
FROM scratch
ADD hello /
CMD ["/hello"]
There's no OS defined in this Dockerfile. Only a precompiled binary hello world app
Also here
https://hub.docker.com/_/scratch
Also in this question:
https://serverfault.com/questions/755607/why-do-we-use-a-os-base-image-with-docker-if-containers-have-no-guest-os
An answerer makes this statement:
why do we base the container on an OS image? Because you'd want to use some commands like (apt, ls, cd, pwd).
So often the OS is just included because you might want to use some bundled low level tools or SSH into it to do some things.
Can someone assist me in relating ISO, Virtual machines, VMware, VMX file and VMDK file together?
I need to understand how all these components relate together. Is there any diagram or chart that shows the linkage among these components.
ISO = Usually an Image of a CD or DVD which you can burn, resulting in a duplicate of the original
Virtual machines = Guest operating systems within a VMware Host server
VMware = The manufacturer of the leading virtualization software.
VMX = the configuration file for a virtual machine
VMDK = The actual virtual disk, or contents of the virtual machine.
It would be hard to put everything together into a diagram because as the commenters already indicated these are very different things at very different levels of abstraction. I'll try to find a relation anyway:
You can imagine a virtual machine being a real computer (== physical machine) simulated in software. Wikipedia From 10,000 ft a VM is a program that emulates hardware and thereby allows you to do anything you could do with a normal computer, e.g., install an operating system.
There are many implementations of virtual machines (with varying performance and feature sets), for instance Microsoft's Hyper-V, Qemu, Virtualbox. VMware is a company that specializes in providing a range of virtual machine implementations as well as many products related to their VMs. In your case VMware probably refers to one of their desktop products such as VMware Player or VMware Workstation.
When you set up a virtual machine in one of these solutions, they provide you means of configuring your virtual computer. Imagine this similar to buying the single parts of a PC in the shop: you need a network card, some processors, memory, hard disks, ... and then you put it all together. This configuration needs to be stored somewhere and in the case of VMWare's desktop products this is what gets stored in a VMX file.
Sometimes you want to have access to a CD-ROM in your virtual machine. You may get this buy passing your physical computer's CD drive to the VM directly. Most of the time however, you will instead pass a CD-ROM image from your physical PC's hard drive. A common format for such CD images is the ISO format. Most VM implementations allow you to simply add such a file to your virtual machine and make it look as if it was a real CD in a real drive.
One of the cool use cases of virtual machines is that you can preconfigure a custom operating system along with a bunch of applications. Then you can take a 'snapshot' of this computer and pass it around to your friends. They can then boot this snapshot in their VM and directly work with all the cool apps you installed without having to go through the tedious steps of installing and configuring the whole system. Such a 'snapshot' is called a virtual appliance. In the case of VMware these appliances are stored in VMDK files.
A late post, but...
First, an ISO file is basically a 'virtual CD/DVD'... which may be mounted in a virtual machine. So there is a direct correlation... analogous even ...with the other entities.
BjoernD may have a point. ;)
As for a Chart...
Computers
Actual | Virtual (simulated in software)
-------|---------------------------------
Dell | "Windows Virtual PC"
HP | "VirtualBox"
etc | "VMware"
| VMware program creates/loads...
| VMware Virtual machine =
myPC.VMX (configuration file)
+
myPC.VMDK (virtual computer system in a file)
+ (optional) myCD-DVD.ISO file
...where myCD-DVD.ISO is a 'virtual' CD/DVD drive.
It is a 'mounted' ISO file (image of CD/DVD disk)
The VMware software lets you run a 'virtual' version of a computer... fullscreen or in a window ...on another computer.