19 thoughts on - Xen DomU Supoprt In RHEL 7 And The CentOS Plan

• Why not? Are not KVM and XEN major, and serious business, parts of the RHEL/CentOS experience?

• Karanbir Singh wrote on Fri, 23 May 2014 13:19:45 +0100:

  What a pity. Not to mention Dom0.

  I’m sorry, I haven’t yet, not even tested RHEL7rc. I just want to raise my hand and say, yes, I would like to have xen support if you can make it happen without too many hooplas. But I won’t be able to help much.

  Kai

• +1 on Xen support, I haven’t had time to test on RHEL yet or poke around in the kernel yet, but has all of the Xen support been removed from the kernel?

  Ant

• +2

  —–Original Message—

• +3 XEN!

• Why do you say that? My minimal testing of the rc doesn’t show any problems installing on Xen 4.4

  Red Hat Enterprise Linux Server 7.0 (Maipo)
  Kernel 3.10.0-121.el7.x86_64 on an x86_64

  localhost login: root Password:
  [root@localhost ~]# mount -t xenfs none /proc/xen
  [root@localhost ~]# cat /proc/xen/capabilities
  [root@localhost ~]#

  Simon

• I had the same results as Simon.

  Running RHEL7rc as a domU on a machine running a Fedora-based Xen hypervisor works fine.

  However, there is no Xen *dom0* support in RHEL7rc. There are no tools either. Last time I checked, Xen support wasn’t evenincluded with libvirt on RHEL7rc. :/

• It has not been removed, but .. let me go in details.

  You can boot an RHEL7 guest as PV, but there are issues:

  1). The FB driver has been unset (CONFIG_XEN_FBDEV_FRONTEND) that means you can
  still do a text-console (in theory).

  2). The Xorg fb seems to suffer from some bug – which is why the Xen FB has
  be turned off.

  3). There are also some systemd and udev things missing.

  I understand that folks are interested in getting this fixed, but I was wondering what the protocol is for getting said patches in the respective RPMS (xorg-some-server, udev, systemd, kernel)?

  Naturally this needs to be fixed upstream first, but once that has been completed it should be fairly easy to backport it.

  Oh, and the Xen support has not been removed – as in, the kernel can easily boot as an PVHVM guest. It is just that the PV part had been.

• Given Red Hat’s focus on and direct freeware support of KVM, why should they burn cycles on open source integration of a product that has a closed source upstream vendor at Citrix? They’d be much better off spending the engineering time on libvirt and getting the NetworkManager configuration tools to correctly support KVM compatible bridging or ordinary network pair bonding, jumbo frames, and VLAN
  tagging. None of that was working correctly on CentOS 6 or RHEL 6
  without hand editing config files, which would be overwritten and scrambled by using NetworkManager to configure anything. I’ve not spent time with the latest NetworkManager on the RHEL 7 betas, and would be very curious to see if they’ve gotten *that* straightened out.

  In Red Hat’s position, I’d contact Citrix and get *them* to do the testing and debugging, which they’ll need to do for their commercial products, anyway. That might get into interesting open source licensing issues, but it’s a lot cheaper than replicating testing labs and doing Citrix’s work for them.

• Just for clarification sake, Xen is now part of the Linux Foundation and XenServer itself is open source as well.

  Pretty much all of the bits to generate the XenServer build and all development of the Citrix product are done on Github now.

  I get the push to use KVM but given the amount of interest and use there was on CentOS 6 with Xen, I believe the effort will still be made to get it into CentOS 7, which is why it would be nice if it was upstream as well.

  From: Nico Kadel-Garcia
  Sent: May 25, 2014 8:58 AM
  To: Discussion about the virtualization on CentOS
  Subject: Re: [CentOS-virt] Xen DomU supoprt in RHEL 7 and the CentOS Plan

  Given Red Hat’s focus on and direct freeware support of KVM, why should they burn cycles on open source integration of a product that has a closed source upstream vendor at Citrix? They’d be much better off spending the engineering time on libvirt and getting the NetworkManager configuration tools to correctly support KVM compatible bridging or ordinary network pair bonding, jumbo frames, and VLAN
  tagging. None of that was working correctly on CentOS 6 or RHEL 6
  without hand editing config files, which would be overwritten and scrambled by using NetworkManager to configure anything. I’ve not spent time with the latest NetworkManager on the RHEL 7 betas, and would be very curious to see if they’ve gotten *that* straightened out.

  In Red Hat’s position, I’d contact Citrix and get *them* to do the testing and debugging, which they’ll need to do for their commercial products, anyway. That might get into interesting open source licensing issues, but it’s a lot cheaper than replicating testing labs and doing Citrix’s work for them.

• I’d not realized Citrix had shifted their publication model. If what is on github is what they use for production, *good*. Are there any major components left that are missing from github?

• Is this an interesting use case? XenServer, for example, doesn’t present a PV frame buffer to any PV guest and I don’t recall anyone ever asking for it. There are better technologies for graphical remote access (e.g., remote X over SSH, RDP, VNC…).

  Really? What? There shouldn’t be anything extra for a pure PV guest vs a PVHVM guest (which RedHat do support).]

  David

• Yes it is. Folks often use ‘vncviewer’.

  I don’t know the details, John Haxby (CCed here) knows them.

• XenCenter still doesn’t have a proper, free equivalent that deals with guest extensions and such, as far as I know.

• The XenCenter codebase is also on GitHub

  https://github.com/xenserver/xenadmin

  Simon

• I am not sure why we are discussing Citrix’s code as what would be going in the CentOS land is the Xen upstream (http://xenbits.xen.org/)
  hypervisor and toolstack.

  That is – the same RPMs and code that has been in Fedora for some time
  (do ‘yum install xen’ under Fedora and you will have the stock Xen code). That code runs with libvirt, so you can use virsh, libvirt (if they are compiled to use Xen libraries), virt-manager, or xl if you prefer.

  Perhaps I am missing something obvious here? Could you please enlighten me?

• Konrad, you are absolutely correct. The discussion on XenServer / XenCenter is off-topic really. Lars

• I’m afraid I brought it up, concerned about the lack of open source or freeware availability of the “upstrream” code base. My awareness of Citrix’s cooperation with open source and freeware developers was out of date. It’s nice to see that Citrix and the main Xen contributors are working well in git: the availability of good management tools
  (such as I’m hearing about with Xenserver) is a vital aspect of any large scale virtualization environment.

  I do hope the RHEL 7, and thus CentOS 7, base releases of these tools will be as up to date and well integrated as possible.

• David Vrabel wrote on Tue, 27 May 2014 13:04:21 +0100:

  It comes in handy for instance if there’s something wrong with networking in the guest ;-) Also, I’ve used it in cases where the load was very high or when the VM was panicking or had some other problem that made it impossible to access via network. At least one get a glimpse on the last text console buffer and may guess what happened.

  So, yes, it’s a valuable asset in emergency situations.

  Kai