Those who don't understand UNIX are condemned to reinvent it, poorly.

Main menu

Post navigation

Libvirt, Xen, again. Alternate history rant.

little update – if you spend some time in trial and error you’ll i.e. learn how to tame the networking stuff in libvirt.

but it’s all so messy 😦

virt-manager won’t pickup a new storage pool unless I restart libvirt-bin and here, there and also over there, things aren’t working. virt-manager sure got better since the RHEL5.0beta where I last used it.

But doing the same thing via native cli will win hands-down, and even comparing to the clicky-intense GUI of vmware vmware will win.

I’m really frustrated by how much these bells-and-whistles tools get in your way if you do something more demanding, and I wish 10 hours that went into little warning icons in virt-manager had instead gone into – for example – gone into making an IO-domain standard in xen.

Sometimes we should re-consider whether to emphasize usability and spread among end users (who would be just as happy on virtualbox) or making available the high-end features that otherwise end up as research topics (like FIDO, vTPM, sHYPE, vnetd). Of course these only help a small number of users right here right now. but if they’re done well, they will advance the whole a lot more than a few coloured icons.

I mean – I really love OS X because it IS user friendly, but the difference is Apple went all the way with it. Yes they ditched ZFS, but also yes, they got a working, lean and somewhat logical GUI. The made the best usable desktop OS. Not two half-assed fails.

Let me put it really drastic: If Xen had commited the IB stack, vnetd and made IO domains and some others of the killer performance hacks to _standard_, added one of the CoW implementations, tmem2 and added an emulated scsi driver instead of using the crap from Qemu, and had pressed that into an ISO image that would’ve given you a Xen setup aimed at top-peformance and top-feature users, it would have been able to outright kill Vmware ESX by now.

Instead we put a lot of effort to get added to the linux kernel, to be able to run as a type2 hypervisor, helped with integration to libvirt, RedHats Xen-abstraction layer, and some more fruitless efforts that might best be filed as “oh please love us” and didn’t get the project anywhere but set back.

Right now the guy who wrote tmem and then tmem2 is waiting for kernel integration. So we got a fully working killerfeature and it has zero adoption because right now we’re waiting for the distros to come around and pick it up, pretty please.

“Right now” in that case is something around TWO YEARS.

I think it pays to put off technical advance if you’re able to make the most well-rounded product. But if you can’t do that, then rather concentrate on being technologically best. Xen should keep pushing forward the virtualization techniques, deliver a userland that exposes most if not all of the features to users and simply stay the best solution around.

It says a lot that after so many years there’s still not a single technique or feature that has been delevoped in KVM, or that it wasn’t the Cisco Nexus V1000 that was the first really cool virtual switch. The second one came from solarflare (i think that was the name) and was developed for Xen like 5 years ago.

And the first one? it was vnetd which was added back in Xen2. Most of the mailing list traffic on the Xen lists concerning it went unanswered or revolved about “deleting that old code”.

I might be getting repetive, but it’s really incredible how idiotic the Xen community acts when it comes to caring about the most advanced features, and how they “generation after generation” keep waiting for full kernel integration while the Linux community clones their features.

Just think of pv_ops – there’s some mails from SUSE developers that pv_ops kernels are in general 1% slower than on hardware (or, as I figure, than when running a native one) and the pv_ops dom0 kernels currently have less features than Xen2 had. Great work guys.

Imagine all that wasted energy instead used to implement the features into the NetBSD dom0 code.

It’s not like that anyone cares what their dom0 runs, as long as the Xen features are there, right?

Came back to this once more:

It should be obvious that libvirt is not to blame for more than 1% of this mess. Libvirt is kinda nice and I fully see it as an option for managing virtualbox, esxi, xen and kvm with the same tool. It’s just my goals in virtualization have always been set a lot higher than that and I don’t generally have to think about opening a VNC console or booting off and ISO very often. I don’t really see why a general tool is good when it limits everything to the smallest common denominator. I’d rather have the ultimate Xen console and the insanest features.

It might be odd, but I also learned ike the cathedral a lot more than the bazaar.

the bazaar has not only open exchange of ideas, but also a lot of petty crime and mud.

the cathedral, much different from that, is an masterpiece, the best humankind can build.