NetBSD Adopts NetBSD/xen for Internal Use

agent dero writes "With NetBSD 2.0, the NetBSD Foundation also released support for a new port, NetBSD/xen. A version of NetBSD meant to run on top of the Xen virtual machine monitor. In this press release the foundation has announced that it is using the port and Xen for much of its internal development, citing security, and ease of use as main reasons for its adoption."

Comments

Xen is cool

[Usquebaugh]

Maybe I'll switch from using Qemu for my kernel sabotage. I would call it kernel hacking but that would indicate some proficiency :-(

BSD dying

[kinema]

Now multiple BSD instances can die on a single machine, securely.

A Great Leap Backwards

[kiore]

From the article

NetBSD 2.0 ... the first to include NetBSD/xen, a port of the NetBSD kernel that runs under the Xen version 1.2 monitor. Significant work to run Xen version 2.0 has recently been completed by Manuel Bouyer and the next release of NetBSD will in all likelihood include this code. The Xen project already supplies a version of NetBSD/xen that runs under later versions of the Xen monitor.

So Xen supplies a NetBSD kernel that runs under Xen 2.0. NetBSD now supports Xen 1.2. How is this a great advance? Why didn't they just pick up the Xen supplied pathces and go with the latest version of Xen?

Re:A Great Leap Backwards

[Nimrangul]

Looks like you need to read harder: NetBSD/xen can run in both privileged and unprivileged virtual machines under Xen 1.2, and in unprivileged virtual machines under Xen 2.0. Perhaps that is the why of it?

Where to get Xen?

[Short Circuit]

When I saw it in Linux Journal (or was it Linux Magazine? Not sure...), I tried to get Xen. I went to their website, but couldn't find a download link.

Of course, now that I've seen it on Slashdot, it's a cinch to find. (Go figure...)

If only we had the WindowsXP port

[mnmn]

... I could switch between a build world of netbsd, and Counter Strike real fast!!!.

That makes me wonder if I can share one nic between the OSes, or put in two NICs, assign one for each OS.

Apart from Zen, would be cool to do a complete replace-boot, as in the OS state is frozen and written to harddisk (some laptop bioses do this), and the state of another OS is read... making switching between OSes, as fast as reading the same amount of data as your used up ram.

Heck I'll just buy another machine and use a KVM switch.

Re:If only we had the WindowsXP port

[Anonymous Coward]

I believe there actually is a windows port, although it might be something earlier than XP. However, you need to jump through some hoops to get educational researcher status (or whatever it's called) from MS.

Re:If only we had the WindowsXP port

[Anonymous Coward]

Apart from Zen, would be cool to do a complete replace-boot, as in the OS state is frozen and written to harddisk (some laptop bioses do this), and the state of another OS is read... making switching between OSes, as fast as reading the same amount of data as your used up ram.

VMWare Workstation (and I assume the rest) can do this. You can also take snapshots, which copy "RAM" and "disk" state to files on the host disk. It seems to only support a single snapshot, but is great for taking a snapshot of a clean system, doing something potentially nasty and then moving back to the snapshot to undo the damage.

I suppose you could copy the files to keep multiple snapshots, however if they are based on diffs of the current disk image and snapshot image, then that could get tricky depending on which is being updated and which is left static (disk image and disk snapshot). Then again, you could always take a snapshot and keep copies of the various versions of the whole directory for that virtual machine. Assuming you had the space.

Re:If only we had the WindowsXP port

[LizardKing]

My understanding of Xen is that NetBSD is one of several operating systems that can run as the primary or "monitor" OS within Xen. Other operating systems (including Windows and Linux) can then be run as secondary OS'es. A research version of Windows could run as the primary / monitor OS, but it is not readily available.

I should add that I've not actually tried Xen yet, but if my understanding of Xen is correct then I'm keen to try it. I'd ideally like to have NetBSD as the primary OS, and Linux as a secondary to test the portability of server side C++ code I'm writing.

Erm

[Anonymous Coward]

Maybe I'm missing something, but how is Xen different from VirtualPC or VMWare?

Re:Erm

[vulcan_pupil]

Xen has been benchmarked to outperform VMWare in certain applications. In addition, Xen allows you to migrate a domain (instance of client OS) to another machine running Xen, live over the network.

Although, another difference is that the OS must be ported to run on Xen. But Linux, FreeBSD, NetBSD have been ported.

Re:Erm

[cant_get_a_good_nick]

VMWare is a hardware virtualization layer. It exports what appears to be (or damn close to it) a full machine to the OS.
Xen can be thought of as a micro-micro (nano?) kernel. it exports a minimalist subset, just enough to virtualize the hardware, absolutely nothing more. as such it's not that hard to "port" your OS to run on this kernel, but there is work to be done,

Re:Erm

[smartfart]

In addition, Xen allows you to migrate a domain (instance of client OS) to another machine running Xen, live over the network.

VMware's ESX can do this. I saw a demo of this last year in Baton Rouge, LA.

However, the really cool thing to me is the fact that the entire client environment is one file. Backing up or restoring a corrupted instance, or even cloning new servers, is trivial... you copy one file from A to B, and you're done.

Re:Erm

[setagllib]

Would Xen be called a kernel? It just provides hardware-like virtual devices (on a virtual bus itself) which require specific drivers and support from the running OS, but in exchange for this you get very good performance and it's pretty simple to implement. The drawback of course is that it /requires/ support from the running system, but NetBSD (and others..) already supports it. Not hard really, all of the abstraction for new busses and hardware is there, and of course the glory of cross-compilation (which is only needed for the kernel).

KVMs (are evil)

[Anonymous Coward]

Beware the KVM switch my son,
The mouse emulator that bites,
The cords that catch.
Beware the loss of functionality.
And shun buttons 3 4 and 5, natch.

Now that I've set the Reverend Dodgson spinning in his grave, let me translate.

Smarter KVMs have a big problem with fancy pointing devices. Many are designed to emulate a mouse to each attached CPU. For various reasons, they emulate a two button MSFT scroll mouse. So anything fancier is lost functionality.

I did find (just after purchasing a different one, natch) a USB KVM that is more like the old hard switches, and doesn't do emulation, that should avoid this problem. Of course you can no longer switch CPUs from your keyboard, because it doesn't trap the keyboard output.

Re:KVMs (are evil)

[O]

I keep my USB KVM on the floor, where I can switch it by pressing the button with my toe. Even more handy than switching with the keyboard!

Server side yet?

[nurb432]

While running it as the client is cool, are there patches to run the BSD's as the server side as well?

Nothign against the use of linux in general, I just prefer FBSD for servers..