Talk:Xen
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using
~~~~:
A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC) : A reply [[User:Sally|Sally]] 12:39, 5 November 2024 (UTC) :: Your reply ~~~~
Init scripts
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
GRUB2 - There needs to be a mention of the "xen" variable for the GRUB_PLATFORM. From 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(orxen-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
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
The comment for app-emulation/xen's use flag "efi" is:
Adds efi boot support, requires LDFLAG -melf_x86_64 for amd64
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
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
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
Should this line below be added to the file following the "Alternatively the bridge may request IP information from DHCP. "?
bridge_br0="eth0"
KERNEL Linux bridge
In kernel linux-4.14.83-gentoo the ability to select 802.1d Ethernet Bridging is modular only. The version of the wiki page (12/9/2018) has "<*>". When you cannot select "<*>", then select "<M>" and then make sure that the bridge module is loaded early by adding the official name of the module, e.g. "bridge", to /etc/conf.d/modules:
#
# 12/8/18 jlpoole: bridge is no longer <*>, so we'll add it here
# so it gets loaded at boot time
#
modules="bridge"
Caution: as I write this, I have not successfully succeeded in getting Xen to run under this kernel version, so this comment is not an endorsement that linux-4.14.83-gentoo works for Xen. --Jlpoole (talk) 23:30, 9 December 2018 (UTC)
- If a kernel option is only able to be a module, then one of its dependencies is most likely a module. A built-in option cannot have a module as a dependency. --Grknight (talk) 00:08, 10 December 2018 (UTC)
Kernel 4.19.23-gentoo has this Help information:
To compile this code as a module, choose M here: the module
will be called bridge.
If unsure, say N.
Symbol: BRIDGE [=m]
Type : tristate
Prompt: 802.1d Ethernet Bridging
Location:
-> Networking support (NET [=y])
-> Networking options
Defined at net/bridge/Kconfig:5
Depends on: NET [=y] && (IPV6 [=m] || IPV6 [=m]=n)
Selects: LLC [=m] && STP [=m]
Grknight's observation that a built-in option cannot have a module as a dependency in the context of the above Help information suggests that IPV6 needs to be addressed. Should these instructions account for the "M" module approach or should the instructions also include a commitment to IPV6? --Jlpoole (talk) 14:22, 23 February 2019 (UTC)
Using LVM volume
The description of dropping '/dev' from the path on physical devices is not working for me, possibly because I don't understand where the "lvm/" is coming from in the example. Perhaps a better way to say it is provide the example absolute path of the lvm and then show how it is translated, e.g.,
- logical volume "/dev/vg00/domu-root" use "[phy:vg00/domu-root,xvda1,w]"
Ditto for a partition: show the absolute path and then the truncated version.
Broken/Dead Link
The link, "Xen network tuning", at the bottom of the page at Additional Resources is dead or broken.
--Jlpoole (talk) 05:10, 7 February 2021 (UTC)
- Thanks! Removed broken link. Mimosinnet (talk)
What's about ARM64 virtualization technology and xen?
> The base system, Domain-0, must have inherent Xen support, however, unmodified domU guests are supported on hardware which implements Intel (VT-x) or AMD (SVM) virtualization technology.
What happens with the ARM64 CPUs in the Raspberry Pi 4B/400? They have at least kvm for arm64 acceleration. Jens3 (talk) 18:11, 15 December 2021 (UTC)
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions_whitepaper has details about Xen on ARM. A recent bug about installing xen on Arm64: https://bugs.gentoo.org/829288 Jens3 (talk) 12:35, 16 December 2021 (UTC)
- Since app-emulation/xen-4.16.0-r1 there is the boot flag boot-symlinks : Symlink xen.gz variants in /boot, disable on fat filesystems which is useful on Raspberry Pis. solved in: https://bugs.gentoo.org/show_bug.cgi?id=829765 Imho the kernel has to be copied manually. There is the option os_prefix for config.txt for Pis. Maybe that can be useful. Jens3 (talk) 08:45, 16 January 2022 (UTC)