OSDev.org

I've been out of the "business" for sometime now and have either forgotten or am not up to speed.

Basically I want to mess a bit around with Debian 6.0 and maybe also Gentoo to prepare for when I get my new Asus eeepc 1015PEM, but as it's not practical to start messing around with my current system, I need a virtual machine of some sort.

Of course it need to be free, or at least free as in "sure, I'll pay for it... Some day...".

I would be pleased if 64 bit is not a problem.

Also the ability to run in full screen and with a resolution of my choice, would be very much appreciated.

If it can boot directly from a bootable image, that too would make things easier.

everything else, I think, is not important.


Looking forward to reading your responses.


Best regards.

berkus wrote:VirtualBox
QEMU
Bochs

depending on what you actually want to do with it.

For starters I'm just going to play around a bit.

I remember trying out QEMU in it's "youth", didn't work too well, but is certainly worth a revisit.

As for Bochs, last I messed around with it, it was pretty clear that it was more than I could handle, but maybe things have changed?

Don't think I ever tried VirtualBox, but I'll certainly check it out.


Thanks

Edit:
I think that virtualbox is best choice for now, but of course I'm still interested if any other suggestions should come along.

Vmware Player is free. As in $0 free.

If you want to run linux, vmware is probably the best choice. If you want to run your own OS, bochs has the largest chance at liking your code. If you want to test your own OS, you'll want all of them (vmware, virtualpc, bochs, qemu, virtualbox) as each of them tends to expose different issues.

Combuster wrote:If you want to test your own OS, you'll want all of them (vmware, virtualpc, bochs, qemu, virtualbox) as each of them tends to expose different issues.

Exactly! That is why I use most of them. I am planning to write an article titled "KNOWN ISSUES WITH EMULATORS AND VIRTUAL MACHINES" based on my personal experience with each of them. Still, I find Virtual PC somewhat useful.

qemu for testing purposes, for productive use VMWare, for i.e. many virtualized servers VirtualBox.

I use bochs for testing code, and any virtual machine for using OS.

There is no such thing as virtualization, i dont know how far extensions such nested pages go, but in most cases its sucky paravirtualization, trapping sensitive instruction and executing own code. Its a bullshit.

Virtualization: The guest OS sees hardware that is not really there. The host "translates" any access to that hardware to something that can be served by the "real" hardware.

Paravirtualization: The guest OS "sees" the "real" hardware the host is running on. Access to the hardware does not have to be "translated", but merely "forwarded".

In either case, the guest OS "thinks" it's the only OS running on the (virtualized) hardware. That's why it is called "virtual".

(You see the difference between virtualization and paravirtualization e.g. in the Xen configuration menus - when selecting "virtual", you can select whether the gfx should be a CirrusLogic what-me-not, VESA, or "headless" server. When you select "paravirtual", you don't get any options - the guest OS will see the gfx card that is really there. Xen is merely an exokernel multiplexing access to that hardware between the guest OS's and the dom0.)

I feel so stupid every time Solar writes anything

Anyway, I had some trouble getting virtualbox running 64 bit. the only answer I could find was that it has to do with a bios setting and while I know I've seen that setting before and could swear that it's enabled, I'm have yet to find it.

At any rate, am now in the process of installing 32 bit debian squeeze and everything seems to work fine, though somewhat slow, but I guess that is to be expected.

Zacariaz wrote:I feel so stupid every time Solar writes anything

Don't. Unless you've been spending time with computers virtually every day for the last 25 years, the last 11 of those professionally full-time, you could say I've got a head start in hands-on experience.

(Gosh. I just realized that avatar picture of me is already 10 years old... )

And up until two months ago, I didn't know what I just wrote about either, because the local XEN machine was set up by a co-worker. He left, so I had to take over administrating the machine.

Solar wrote:Paravirtualization: The guest OS "sees" the "real" hardware the host is running on. Access to the hardware does not have to be "translated", but merely "forwarded".

In either case, the guest OS "thinks" it's the only OS running on the (virtualized) hardware. That's why it is called "virtual".

When you select "paravirtual", you don't get any options - the guest OS will see the gfx card that is really there.

Err, sorry, but no.

PV means that the guest is aware that it's virtualized. Therefore it doesn't even try to access hardware directly, but instead communicates with an API that the hypervisor provides. Think of it like a syscall API of the hypervisor that the kernel uses, just that they are called hypercalls.

Consequently, a paravirtualized kernel doesn't see an IDE disk or a e1000 network card like fully virtualized guests do, but it sees a PV disk/network card/framebuffer device, which is basically just an API to the hypervisor. And only the hypervisor contains the actual network driver that accesses the hardware. Try a lspci in a PV Xen guest, I think it should be pretty empty (unless the PV devices turn up as PCI devices, but I don't think they do with Xen)


Anyway, if we're talking about virtualization for productive systems instead of development here (and assuming that by qemu you all meant the TCG-based emulator), what about KVM?

Kevin wrote:PV means that the guest is aware that it's virtualized.

Ah... now that actually makes real sense.

(@Zacariaz: See? The stupid one here was myself, actually. Teaches you not to "judge by reputation" - the big old ones get it wrong just as easily.)

Now I understand why there's a "paravirtualized XEN driver package" for Windows... because you don't need drivers for the host's hardware, but drivers using that paravirtualization API...

I stand corrected. Thank you for that piece of enlightenment.

Maybe one interesting thing to add is that you can use a mixed mode: Use hardware virtualization for the things that are directly supported (CPU, memory and so on) but use a PV device for things like disk and network to achieve better performance. You can do this with Xen, and with KVM it's even the normal mode of operation (and its virtio-blk/net devices actually do turn up as PCI devices in the guest).

Although i'm not an osprogrammer for long,
Virtualizing i'm very experienced in.

There is no best virtual emulator.
They all have good and bad things.
Bochs is better for code testing (advanced debugger and much config)
But i think you want virtualbox (64bit patch on site):
It has (unlike bochs) several presets for diffrest os/distro.
I have an win2003 in it.
Setup is simple:
Download/install vb (short for virtualbox) (if you're on windows: ignore driver warnings and press continue (they are the glue between real and vb but there not signed))
Next press the new button in the gui.
Select the correct os/distro/version.
Mem: it sets a fine amount by default
Now: create a new virtual disk (size of your choise, 5gb min)
Now finish wizard.
Download install iso for os.
Press settings for your vm.
Go to storage and link the iso to its cddrive.
Go to system and select cd and hd as boot dev (cd first)
Save and press run!
Go through the install process of the os (it installs on its virtual disk, formatting does nothing to your own data).
After successful install (shut the vm down), go to settings for your vm and remove the iso.
Save and run. From now on just press run to start the vm.
Voila, your running an virtual os! Have fun!