When we work with type 2 hypervisors it is very easy to say which OS is the main one. For example, if you install some type 2 hypervisor on Win 7, and launch Win 95 inside this hypervisor, the main OS will be Win 7. The conception is obvious.
However, it's not so obvious with type 1 hypervisors. I never worked with them before.
You have few operating systems on top the hypervisor. So... Which one of these OSs will be the main one? How this question is resolved? And probably (just a guess) there is no such thing as "main OS" in this case?
I don't think that "main" operating system is a defined term.
A type 2 hypervisor is an extension to an operating system, which is known as the host operating system when guest operating systems are running on top of it. A host operating system runs directly on the hardware and needs to have specific code to interact with the hardware (e.g. the NIC, the disk, etc.) and provide abstractions to user-level programs. The hypervisor simply extends the functionality of the host operating system to allow guest operating systems to run on top (e.g. when the guest operating system wants to write to the hard drive, the hypervisor translates this request to a form that the host OS can understand so that the host OS can make the disk access).
A type 1 hypervisor runs directly on the hardware without an operating system. A type 1 hypervisor is basically just a stripped down operating system with the functionality necessary to allow guest operating systems to run on top. When the guest needs to write to disk or do some other privileged operation, the type 1 hypervisor receives the request and acts on it. Perhaps the type 1 hypervisor is what you would consider the "main" OS? Regardless, I would avoid using that term.
I would argue that the "main" OS would be the Hypervisor software itself, as it runs directly on the hardware and supports the virtual operating systems, as well as boots on system startup.
Related
I know Hyper-V is type 1 or native hypervisor, meaning it sits on top of hardware and doesn't require an operating system, i.e. talks to the hardware through the ISA interface).
But I don't understand why does it require hardware assisted virtualization? Does it mean Hyper-V is not full native hypervisor because it requires another part (put in hardware)? Does every native hypervisor require hardware virtualization?
Because without hardware virtualization it would have to run an emulation which comes with a BRUTAL performance implication. There is no way to do proper virtualiaztion without either interpreting a significant number of machine code, or have hardware support for this. EVERY native hypervisor requires hardware virtualization - which is, btw., nothing new... it was in the firstp rocessors mit 60s, iirc (196x). Yes, this is that old. VMS - the Mainframe operating system - is acutally short for... "Virtual Machine System". The processors back then had hardware virtualization.
How can an application detect when the hypervisor has resumed its guest OS after suspending it due to, for example, migration? Is there an API for it, depending on the specific hypervisor, or is there something in the environment (Linux or Windows) that unambiguously indicates resumption?
There's not really anything that I can think of off the top of my head. The guest OS, for the most part, doesn't really know it's virtualized so it doesn't have a concept of what host it's on or whether or not it's being migrated and/or suspended at the hypervisor level.
Is there a particular use case you can share where this would be helpful?
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.
I've seen programs like magicdisc create virtual cd drives and mount them on the machine. How do these programs trick the operating system into thinking there is a new hardware device attached to it?
I imagine I would have to write a driver for the virtual hardware, and I am comfortable in C so that doesn't sound terrible, but how do I make the OS think there is a piece of hardware attached to it that isn't?
Thanks!
Usually the operating system has different layers and libraries, at some point there is a library that sits between something above it and the actual hardware, you fake it there, if there is some sort of read sector call, you pretend to read a sector using that sector address, read it from a file, whatever. Each operating system (windows, linux, etc) may do things a different way.
Probably you are familiar with C as application level, which is above OS.
The virtual driver is a piece a software, but need to write in proper locations the settings: Registry at Windows, some config file at some Linux. You need to handle OS level calls and callbacks at Kernel level. Than you will desire the software too to communicate with your device, probably integrated into OS Shell. At least 2 layes will be , if not 3 or more.
For eg windows xp you can make a virtual graphic card(and intercept various things), for Vista not, just with a trick :)
It is very-very OS specific.
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?