May be asking for too much, but is it possible to instantly switch between a linux host and a windows host?
Someone must have thought of a way to do this. Apple maybe?
What about automatically hibernating one host and de-hibernating the other at the press of a button?
What if memory is split in 3 parts:
1. one third for running o/s, either linux or xp
2. one third for the hibernation file of linux,
3. one third for the hibernation file of xp
Tweaking something very low-level obviously.
UlyssesOfEpirus wrote: No, I mean host.
The Host is the Physical Machine and the Guest is the Virtual Machine so if indeed you're talking about two Hosts then what does "Instantly switch between linux and XP hosts" have to do with VMware Workstation!?
It's that guys hanging around these forums may have a detailed understanding of virtualization ie what machine code is running to switch between virtual machines a million times a second. And therefore must have an idea how the switching between hosts rather than VM's could possibly be done and the hardware obstacles to this (such as real-mode versus whatever).
Or is there a subforum available where the developers of vmware can be contacted?
In VMware terminology: 'Host' is the hosting operating system, so on a single hardware there can be only ONE host operating system. There cannot be any 'switching' between 'hosts'. The 'host' operating system runs the 'guest' operating system.
In ESX environment the host OS is the ESX itself.
In Workstation environment the host OS is the operating system you installed to your laptop (e.g: windows XP).
Xen has a bare metal hypervisor product: XenClient http://www.citrix.com/English/ps2/products/product.asp?contentID=2300325
I have heard that VMware is going to release a product like this.
But in this case the situation is the same: there can be only one 'host', and in this case, the Xen is that.
Xen is for a linux host supervising linux guests, is vmware going to do the equivalent with windows xp supervising xp and linux guests?
"on a single hardware there can be only ONE host operating system"
Let's not get stuck with definitions, the idea I'm talking about is NOT virtualization. It just needs the detailed cpu understanding that virtualization's developers have.
I only used the word "host" to prevent the "guests can already do that" response. But also because I want to run vmware workstation and various VM's on both host options. Having to reboot to switch between the two hosts takes too long.
If you have 2 Hosts meaning 2 physical machines and you want to switch between them then use a KVM Switch.
If you're talking about 1 Host as in 1 physical machine that physically dual boots to either Windows XP or Linux then only one physically installed OS on a physical machine can be booted at one time therefore the paradigm you're eluding to doesn't exist and even if it did it has not to do with VMware Workstation in the context you've presented here, so why are attempting to discuss nonexistent hardware technologies in virtuialzation forum?.
"why are you attempting to discuss nonexistent hardware technologies in virtualization forum"
Gave the reason in the edit of the previous post, here it is again:
"... is NOT virtualization. It just needs the detailed cpu understanding that virtualization's developers have"
And let's face it, the inventor of virtualization did not go "why waste time investigating non-existent hardware technologies?". Or "640k of ram should be enough for most applications".
Other respondents are getting hung up on your use of terminiology.
Your question actually pertains to "hardware virtualization" and so the use of "Linux Host" and "XP host" is triggering the imporper corrections...
That said, I think what you want is ESX (or GSX?). Basically the a slim hypervsor is installed in the machine, this software "partitions" the hardware such that particular fractions of memory and various disk devices or partitions are assigned to the various virtual partitions. Then different operating system instances can be installed in each instance.
In such a setup then, one computer is running more than one full operating system. Since none of the operating systems are subordinate to any other the "host" vs "guest" terminology does not apply.
In Host OS + many Guest OS configs (such as vmware player or vmware workstation) the guests are called guests because, for example, the guest OS disk operations pass through the host OS's disk queue managment and so on. This forms a hirearchy.
In partitioned hardware, each installed operating system is completely unaware of and insulated against all the of its peers. Their requests pass directly to the hypervisor. In this case there is no hirearchy, just a list of peers.
So drop the "host" and "guest" terminology and go look at the the server and hardware virtualization products.
Note that these hypervisor technologies are likely to be more expensive as they have a generally higher level of complexity and craftsmanship. But these dedicated hypervisors are also much faster and more efficent as there is no need to translate requests and actions from guest operations to host operations and so forth.
switch between hosts ... ?
ok - lets consider you have a windows setup and a linux setup on one machine.
Both OS are somehow running ... and can exist in a suspended state ready to start any time ...
very vague ... but for arguments sake lets think on
Who then does the switching between both states ???
... and again you have to introduce another host-OS - one that does the switching and managing of the different states ...
By the way - I don't think that you really want to switch between hosts - I guess you want VMs that are good enough so that you no longer need a host in the traditional way
Regarding ESX, unfortunately a second computer would have to be bought here to control it, and I am also put off by the fact that video and graphics are transmitted via an ethernet cable which must make it unsuitable for many applications. But let's say we go to ESX anyway.
If the new computer has a VT-x cpu and running VM's at full speed, will the 5-year old controlling computer give a full speed experience to the user? Or better off with vmware workstation on the new computer? Not with windows 7 but with 64bit linux as the host, specifically a very lean variant of 64bit ubuntu?
"I guess you want VMs that are good enough so that you no longer need a host in the traditional way"
That's true, yes, I want the fastest possible VM's. But I also want to experiment with all sensible host options, and ESX does not seem to be one for my applications and hardware.
So the change of subject as above is wrong. I want hardware details to understand what is or is not possible with an x86 cpu.
"Who then does the switching between both states ???"
Aha, there you go then, the idea of a hypervisor is born that is even simpler than ESX. Where one VM has full access to the computer at a time, at full speed, and the other VMs are frozen. So peripheral interfacing is then much simpler, all peripherals are completely owned by the running VM.
It is only when switching between o/s's that the state of the peripherals has to be saved and restored, which is what hibernation technology already includes, so hibernation is proof that instant switching between operating systems is possible. Hibernation saves memory to disk, but what is there to force it to store memory to disk and not some reserved memory, reserved at a level lower than the ramdisk concept?
what about switching between hibernated OS stored on SSD ?
probably that soon is fast enough for what you had in mind ?
You have a strange definition of "simpler". Since devices have to be initialized, which is what takes all that time when an operating system boots etc, transferring ownership of device between two "running" operating systems would require the device be frozen and shut down for the first OS and then initialized and "melted" for the second OS by the "simpler" hypervisor.
You mentioned hybernation, there is a reason that takes time.
Further, if anything changes in the state of your file systems or devices then your hybernation wake-up would fail.
So what you need to do to acheive your goal can be done, but not "instantly". Go get a RocketDrive(tm) or similar [e.g. a "hard disk" made entirely of RAM and a battery] and put your hybernation targets (windows hyberfile.sys, linux primary swap, etc) in partitons on that drive. The set up a good smart boot loader (like grub). Make sure none of your OS instances "share" any local (not NFS etc) partitions of any sort. Then set up hibernation hot keys.
Time to switch is going to be "freeze-reboot-pick-os-melt", but this is not "instant."
It's not like the inventors of these systems just put all that hibernation time in there to annoy you, that is work that has to be done. period. So you either partion your hardware or you hibernate your OS. There is no magical third mode.
"Since devices have to be initialized,"
This is an arbitrary assumption. Hibernation has a purpose other than switching o/s's, by definition de-hibernation starts from a shut down computer. And the little hardware driver development I did 20 years ago tells me initialization is not required if you are starting from a valid state because each device has a state held by internal registers that can be saved and restored at will. Remains to be seen if the same applies to today's pc's. Maybe it's ok if a video frame buffer is left unsaved, because it will be painted with new data immediately.
"Further, if anything changes in the state of your file systems or devices then your hybernation wake-up would fail."
File systems are ok as long as each o/s does not mess with the other's system partition, which can be made harder by turning one at a time into a hidden partition. And if you're in the middle of modifying something on a data partition, might as well be banned from switching over until all data files are closed.
Something close to instantly switching between a linux host and an xp host is now possible. Colinux runs both hosts in parallel.
A few cpu cycles will be stolen by the host you are not currently using. Should be ok.