I have a windows 10 host operating system that supports virtualization. Next, I have an Ubuntu 16.04 virtual machine I created using virtualbox. For development purposes, I need to create a virtual machine inside my guest Ubuntu virtual machine. Unfortunately, I can't enable VT-x option in my guest Ubuntu machine to create a create a virtual machine inside my Ubuntu guest. Any information on how enable VT-x option on my virtual box inside my virtual Ubuntu machine would be appreciated.
Edit: I had that this may be accomplished through PCI Passthrough for VirtualBox. If so please detail how.
Lastly, my problem is similar to this guy's but with exception I can't seem to create an UBuntu32bit box.
Any information on how enable VT-x option on my virtual box inside my virtual Ubuntu machine would be appreciated.
You simply CAN'T.
VT-x is a hardware capability:
In 2006, both Intel (VT-x) and AMD (AMD-V) introduced limited hardware virtualization support that allowed simpler virtualization software but offered very few speed benefits. Greater hardware support, which allowed substantial speed improvements, came with later processor models.
Since VT-x requires hardware capabilities to work, there's no way for the "outer" virtual machine in your nested VMs to provide that capability to the "inner" VM. The "outer" VM doesn't have any actual hardware.
If you have to run a VM inside your VM that requires some of the capabilities that VT-x provides - such as the ability to run a 64-bit OS - you can try QEMU for the "inner" virtual machines. It'll be slower since it's an emulator and not true virtualization, though.
Suppose in my pc I have Ubuntu as Host OS. Now I installed a Virtual Machine say VirtualBox (hypervisor) and then deployed a centos and a redhat os inside that as guest OS.
Suppose CentOS and redhat has 2 processes running and Ubuntu is running 3 processes. So following are my questions:
There are how many processes that Ubuntu is having?
Is there any difference between GuestOS and HostOS processes?
If all guestos runs as a process then they will get less time as compared to other process running on host os.
Please clear my doubts here.
Thank you.
Well let me clear your doubts,
First of all there aren't any specific number of process for an OS, its called as cores or threads, technically you can define how many cores or threads you want to use on your virtual machine and it depends on the system configuration you use.
Secondly Guest OS is what you have created in the virtual machine and host is what your laptop or pc actually run. Host OS uses the actual hardware for the working whereas the Guest OS uses the virtual hardware like number of cores and type and size of hard drive defined by the user while adding a virtual machine.
Third, as I mentioned earlier Guest and Host OS works on the configurations used by you, if you user higher amount of cores/ threads in setting your virtual machine the Guest OS will get higher speed.
Ideally the virtual machines are used to test and create some functionality of the Operating Systems without affecting the internal OS, so you can think of it as a your parents house where you can live and grow but at the end you cannot go away from the fact that their contribution is more and so you cannot go beyond their features without leaving it and making your own home.
Linux operating systems are multi-threaded operating system. The host OS would consider virtual box as a thread. You can define number of cores and virtual hard disk size for guest OS by using virtual box.
Since virtual box runs in separate thread and other operations of host OS runs in separate threads, there would be less effect on speed of processing. But I've observed big variances in processing speed in systems which have low memory. Each and every thread needs specific allocation of memory for its smooth operation. So systems having more than 2 GB RAM managed virtual box very well.
What's the difference between process virtual machine with system virtual machine?
My guess is that process VM is not providing a kind of an operating system for the whole application for that OS, rather providing an environment for some specific application.
And system VM is providing an environment for an OS to be installed just like VirtualBox.
Am I getting it correct?
Another question is the difference between the two different implementation of system VM: hosted vs. stand-alone.
I'm a beginner studying OS, so easy and understandable answer would be greatly appreciated :)
A Process virtual machine, sometimes called an application virtual machine, runs as a normal application inside a host OS and supports a single process. It is created when that process is started and destroyed when it exits. Its purpose is to provide a platform-independent programming environment that abstracts away details of the underlying hardware or operating system, and allows a program to execute in the same way on any platform.
A System virtual machine provides a complete system platform which supports the execution of a complete operating system (OS),Just like you said VirtualBox is one example.
A Host virtual machine is the server component of a virtual machine , which provides computing resources in the underlying hardware to support guest virtual machine (guest VM).
The following is from http://airccse.org/journal/jcsit/5113ijcsit11.pdf :
System Virtual Machines
A System Virtual Machine gives a complete virtual hardware platform with support for execution
of a complete operating system (OS).
The advantage of using System VM are:
Multiple Operating System environments can run in parallel on the same piece of
hardware in strong isolation from each other.
The VM can provide an instruction set architecture (ISA) that is slightly different from
that of the real machine
The main draw backs are:
Since the VM indirectly accesses the same hardware the efficiency is compromised.
Multiply VMs running in parallel on the same physical machine may result in varied
performance depending on the workload imposed on the system. Implementing proper
isolation techniques may address this drawback.
How much valid are the valgrind logs showing invalid accesses and data races,when running it in virtual machine and not in a native linux system. The reason being,in a virtual machine,everything is virtual.
Unless you are writing some kernel specific stuff I would say that they are all valid. Maybe just your virtual machine has different timings than real machine?
If hardware support is a must for virtualization, how can Java Virtual Machines run on machines without support for virtualization ? Or is JVM not a virtual machine ?
A JVM is not virtual in the same sense as a VirtualBox or VMWare virtual machine. It is a 'machine' that implements the Java bytecode, not a virtualized version of actual hardware.
The term-of-art 'virtual machine' was coined a very long time ago for the following scenario:
make up a computer, like Knuth's MIX.
write a computer program that implements the made-up computer.
run programs
When this virtual machine runs, it's a completely ordinary program, running completely in user mode. It needs no special help from the hardware or operating system to work reasonably well. This is especially true of the JVM, since the Java byte code does not deal with low-level hardware I/O or other things which are hard to simulate.
Later, historically, (to pick a particular instance), IBM invented VM/370. VM/370 uses the other sense of the term 'virtual machine'. In this later sense, the hardware and operating system cooperate to allow a single physical machine to host multiple virtual instances of (more or less) the same architecture, in which multiple copies of the whole operating system are written as if they are running on more or less bare hardware. Later, the X86 was designed with features to facilitate this.
So, yes, any virtual machine is making use of some physical hardware, unless you implement it with pieces of paper passed around a table (pace John Searle). But when the virtual machine bears no resemblance to the machine it is running on, then there's no need for special help from the operating system and hardware, and no need for anything as complex as VM/370, or VMware.
If hardware support is a must for virtualization, ...
Let me stop you right there :-)
There is a difference in concept between the JVM (software virtualization) and (for example) a VMWare VM (hardware-assisted virtualization).
The JVM (and other software-based VMMs such as the ones that allow to to emulate x86 on Solaris hardware - I think Bochs and possibly DosBox fall into this category) runs like any other application, using the operating system to gain access to the hardware, or emulating its own hardware purely in software.
VMWare, and the other VMMs optimised for speed, rely on hardware support. In other words, they run on the hardware as if they have full access to the hardware and, only when they try to do something they're not supposed to does the OS captures that attempt and fake it.
That's why VMWare runs so much faster than the software-only emulators. It's because, for the vast majority of the time, it's actually running on the real hardware.
The JVM is a virtual machine, but it doesn't require any additional support from the Operating System. Instead of virtualising instructions for a particular CPU it executes java bytecode.
The JVM is a virtual machine for running Java, in other words it emulates a machine which would be capable of running java. It is a confusing choice of names, but it comes from the general meaning of "machine" not from the more common Virtual Machine meaning.
The JVM, like a regular VM emulates the execution of instructions, but in the case of the JVM the instructions being emulated are Java Instructions, and in the case of a VM they are Hardware Instructions as would be executed by an OS running on the same hardware.
Yes the JVM does access hardware, however this is why you install a MAC or WINDOWS JVM since the instructions are translated by the JVM and acted upon depending on the installation of the JVM, for example, open file dialog on mac opens the mac dialog and windows JVM opens the windows dialog.
So its not being virtualized by the system, but the bytecode is being virtualized by the JVM you installed. It's basically like an application that reads something(bytecode) and does something(access hardware, or other stuff).
It should be noted that nothing stipulates that a JVM does not (have to) have HW virtualization access. There are notable exceptions, but to which the answered poster alluded, few CPs exist that run Java bytecode natively. Maybe someday a Java bytecode HAL or TIMI will be commonplace to put the JVM into the same class as the formalized HW virtualization?