Template talk:Virtualization software

Xen missing?

I think it is somewhat unfair and misleading to have Citrix XenClient and Citrix XenServer listed, but not Xen. These are not all exactly the same thing, and in particular, Xen per se is essentially independent of Citrix now. The list as it stands, I feel, gives too much credit to Citrix and not enough to the people who work on Xen. At the same time, I recognize that it's undesirable to have clutter and redundancy in these lists. Thoughts? ProfStevie (talk) 22:04, 24 April 2013 (UTC)[reply]

Hello. I have two thoughts: First, you forgot to add a title to your message. (Sorry, it was eating me.) Second, yes, I share your concern. I originally included Xen alone. Wikipedia does not have an article on Citrix XenServer. (XenServer redirects to Xen.) So, I am putting Xen back, but what should I do with the link to XenServer? Keep it or kick it? Best regards, Codename Lisa (talk) 06:28, 25 April 2013 (UTC)[reply]

Thanks for adding the title; I've only done a little bit of Wikipedia editing so I'm not always clear on the best practices. I would vote for removing XenServer. I think it's fair to say that Citrix XenServer is a variant of Xen (rather than the other way around, which was essentially the point I was trying to make in the first place), and especially since it doesn't have its own article, it probably doesn't need its own link in this list. Thanks, ProfStevie (talk) 16:07, 25 April 2013 (UTC)[reply]

PearPC? Really?

I don't really think PearPC should qualify as “virtualization”, because it's an emulator. I suppose the lines are blurring with regard to this, but I view “runs an architecture on another architecture” as definitively emulation, rather than virtualization. I'm one of the principle developers, so I don't feel comfortable just bulldozing my opinion on the matter into the template. But I have never though of PearPC as a virtualizer… --Puellanivis (talk) 23:12, 27 July 2016 (UTC)[reply]

Hi.

Emulation is a subcategory of hardware virtualization today. It has not been always this way, because hardware virtualization didn't exists in its current form 10 years ago. But that's how things are today.

Best regards,

Codename Lisa (talk) 16:57, 28 July 2016 (UTC)[reply]

Thanks for the explanation of the semantics shift. I suppose, as with most of my knowledge, it comes from just before the topic exploded in popularity, and thus carries these sorts of silly archaisms. --Puellanivis (talk) 22:12, 29 July 2016 (UTC)[reply]

CoreOS

CoreOS is the name of a company, and its main product (which I assume is meant to be referenced here) is Container Linux. But Container Linux is just a bare Linux, engineered from scratch for containerization. I think we should replace "CoreOS" by "rkt", witch is an alternative to Docker, meant to be based on Container Linux. --Galeop (talk) 12:38, 14 September 2017 (UTC)[reply]

bhyve

Should bhyve be moved under Independent, as it supports many different types of guests?

-- KJ4IPS (talk) 17:19, 28 December 2017 (UTC)[reply]

Subgroups of "OS-level virtualization"

Hey, everyone. 😊 I'm having a little bit of trouble understanding the subgroups of the "OS-level virtualization". Right now, they are "OS implementation", "Containers", "Kernel features" and "Orchestration". "OS implementation" is the most troublesome. Its name implies it is something that OS implements, in which case it begs the question: "What's the difference between 'OS implmentation' and 'Kernel features'?" Flowing dreams (talk) 07:07, 17 August 2019 (UTC)[reply]

I agree that "OS implementation"/"Containers" is confusing, however I think it's now even more confusing. Complete solutions such as FreeBSD jails, LXC, Solaris Containers are listed under "Backends"; this is clearly wrong, but I acknowledge that it's not entirely your fault. We used to have four categories:

* OS containers: They are complete solutions that focus on using OS-level virtualisation to provide complete instances of operating systems. They usually call init to initialise the OS.

* Application containers: They are complete solutions that focus on using OS-level virtualisation for isolation and redistribution of application software. They may not necessarily call init.

* Kernel features: These are kernel features available to userspace via system calls that play a significant role in the enablement of container solutions.

* Orchestration: Systems for automated configuration, coordination, and management of containers.

I'm going to restore these in an attempt to bring back some sanity to the "OS-level virtualization" group. If someone disagrees, then please discuss it here. -- 192.195.66.5 (talk) 19:45, 22 November 2019 (UTC)[reply]

vkernel needs a new subgroup as it does not fit the description of a container. It runs a complete kernel in userspace akin to User-mode Linux -- 192.195.66.5 (talk) 20:02, 22 November 2019 (UTC)[reply]

I'm going to move "Container Linux" under "Application containers" as rkt, which is akin to Docker and lmctfy. I'm not sure if we need another subgroups for OSs designed for containers like Container Linux, DC/OS, etc. Please discuss. -- 192.195.66.5 (talk) 20:25, 22 November 2019 (UTC)[reply]

I'm going to remove "Turbo". It does not fall under any of these subgroups and I'm not sure that it merits its own subgroup. Besides, it's already listed under the "Application virtualization" group. If you believe it should be restored under "OS-level virtualization", please discuss. -- 192.195.66.5 (talk) 20:38, 22 November 2019 (UTC)[reply]