Talk:Xen

Init scripts

Talk status

This discussion is still ongoing.

The init script section:

   To add these daemons directly to the default runlevel perform the following:
   root #rc-update add xencommons default
   root #rc-update add xenconsoled default
   root #rc-update add xendomains default
   root #rc-update add xenstored default
   root #rc-update add xen-watchdog default

   These daemons should only be started when the system boots into Xen. As this may not always be the case, it may be desirable to keep these services out of the default runlevel. One possible alternative is to utilize an alternate default runlevel via the softlevel kernel parameter. The following example, based on this blog post, creates a new runlevel named xen.

   First create the new runlevel:
   root #install -d /etc/runlevels/xen

   Stack the default runlevel onto it:
   root #rc-update -s add default xen

   Then instead of adding the xen daemons to the default runlevel add them to the xen level:
   root #rc-update add xencommons xen
   root #rc-update add xenconsoled xen
   root #rc-update add xendomains xen
   root #rc-update add xenstored xen
   root #rc-update add xen-watchdog xen 

If you are going to have mutually exclusive alternatives, the flag the user ahead of time with something like: Init Scripts: There are two alternatives: 1) always starting Xen 2) running Xen when appropriate.

Better yet, why not just have the "xen" runlevel approach only? This way you're covered no matter what and if someone is maintaining it, they will have enough saavy to understand that a separate run level "xen" has been created, so you're not really added complexity.

Also, if the "xen" runlevel approach is adopted, the instruction:

  # Replace the default runlevel with "xen"
  GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT="softlevel=xen"

Needs to be considered since it overrides an earlier suggestion on this page:

  GRUB_CMDLINE_XEN_DEFAULT="dom0_mem=1024M,max:1024M"

GRUB2

Talk status

This discussion is still ongoing.

GRUB2 - There needs to be a mention of the "xen" variable for the GRUB_PLATFORM. From https://wiki.gentoo.org/wiki/GRUB2_Quick_Start See: To install GRUB2, first set the GRUB_PLATFORMS variable with one or more appropriate values in the system's make.conf. If one is coming from a regular-built Gentoo system, as currently all users are since there currently is no documentation on building a XEN Gentoo from the outset, then following the instructions and running "grub2-mkconfig -o /boot/grub/grub.cfg" will not cause the system to be configured for XEN. I appears one needs to add in /etc/portage/make.conf the flag "xen" (example: ) in the GRUB_PLATFORMS variable and then 1) emerge sys-boot/grub, 2) install grub, and 3) configure.

Another issue: how the user compiles can affect whether the .config is placed in /etc/kernels. I had been using genkernel throughout building my kernels on a new box. My first build was to get a Gentoo operating system up and running, and then the second phase is to modify the kernel per this wiki and compile for zen. I successfully compiled and the appropriate /boot/xen... files were staged, so I'm certain I only used genkernal throughout. Yet, I have a discrepancy: my /etc/kernels/kernel-config-x86_64-4.4.26-gentoo has a time stamp of Nov 11 03:10, whereas my /usr/src/linux/.config has a time stamp of Nov 12 13:39 and my /boot/xen.gz has a time stamp of Nov 12 16:42. So something is amiss and the bottom line is the my .config that has all the XEN settings only exists under /usr/src/linux, whereas the /etc/kernels/kernel-config-x86_64-4.4.26-gentoo does not -- this causes GRUB2 not to trigger the XEN build. It's a trap and I'm not sure of the causes, but I thought I'd bring it up here as the documentation might warn users. Ideally shouldn't the timestamps for a build be the same or very close for /etc/kernels/kernel-config..., /usr/src/linux/.config, and the XEN files under /boot? In my case they clearly are not, so I've done something I'm not aware of which instructions here might caution me about. Again, I'm certain I've only been using genkernel as I do not remember setting any deploy flags or copying anything over to /boot.

You're correct in asserting that the GRUB_PLATFORM should have the xen (or xen-32) value set for those wishing to boot to Xen using GRUB2. I can update this.

As for the other issue, I'm not sure I understand what you're trying to explain. I haven't had an excuse to use xen yet. Also, please remember to sign your comments on discussion pages. Kind regards, --Maffblaster (talk) 06:11, 31 December 2016 (UTC)

grub2-mkconfig

Talk status

This discussion is done.

Is the command "grub2-mkconfig" obsolete now given that grub is slotted? The current version references " grub2-mkconfig " when it probably should reference "grub-mkconfig".

Hi Jlpoole . Yes, grub2-mkconfig is now obsolete; replaced by grub-mkconfig. There's an enews item regarding the update on 2016-08-11. Gentoo users should read enews before doing system upgrades. Please update any locations still using the old command. Kind regards, --Maffblaster (talk) 17:52, 14 November 2016 (UTC)

USE FLAG "efi" for app-emulation/xen

Talk status

This discussion is still ongoing.

The comment for app-emulation/xen's use flag "efi" is:

   Adds efi boot support, requires LDFLAG -melf_x86_64 for amd64 

https://wiki.gentoo.org/wiki/GCC_optimization#What_about_LDFLAGS.3F tells us:

   What about LDFLAGS?
   The Gentoo developers have already set basic, safe LDFLAGS in the base profiles, so they do not need to be changed. 

So, if one has a 64 bit system and efi booting, one needs to use the "efi" flag and therefore one needs to have a special LD_FLAG in /etc/portage/make.conf? If so, then there should be step to the effect:

If you have efi booting, make sure /etc/portage/make.conf has"-melf_x86_64" as a flag in LD_FLAGS, and if no LD_FLAGS are present in your /etc/portage/make.conf file, then add:

   LD_FLAG="-melf_x86_64"

/boot/xen-4.*.*.config

Talk status

This discussion is still ongoing.

The emerging of app-emulation/xen results in the creation of a configuration file under /boot. In my case, there is a file /boot/xen-xen-4.7.1.config. When I run grub-mkconfig, grub-mkconfig incorrectly determines that the file xen-4.7.1.config is a kernel file because it's file selection algorithm is based on "xen-" or the like. So what purpose does xen-4.7.1.config? And is placement of it under /boot the best location? It doesn't make sense for grub to create a menu item based on xen-4.7.1.config, so either grub's XEN configuration file needs to be tweaked, or this xen-4.7.1.config should be placed elsewhere.

Xen Overview & Types of Virtualization

Talk status

This discussion is still ongoing.

I think this wiki needs to distinguish the various kinds of virtualization and then identify which one will be implemented further one. Perhaps more than one type might be implemented? I found http://www.virtuatopia.com/index.php/An_Overview_of_Virtualization_Techniques to be very informative and complete, especially at the end http://www.virtuatopia.com/index.php/An_Overview_of_Virtualization_Techniques#Hypervisor_Virtualization where three types are identified: 1) Para, 2) Full, and 3) Hardware.

Hi, please remember to sign your comments to discussion pages. You have left a lot of new discussions here without signing. I'll try to review each of them. Thanks. --Maffblaster (talk) 20:20, 30 December 2016 (UTC)

3.2 Bridged interfaces

Talk status

This discussion is still ongoing.

Should this line below be added to the file following the "Alternatively the bridge may request IP information from DHCP. "?

    bridge_br0="eth0"