Package Details: xen 4.19.1pre-1

Git Clone URL: https://aur.archlinux.org/xen.git (read-only, click to copy)
Package Base: xen
Description: Open-source type-1 or baremetal hypervisor
Upstream URL: https://xenproject.org/
Keywords: hypervisor virtualization xen
Licenses: GPL2
Submitter: sergej
Maintainer: Refutationalist
Last Packager: Refutationalist
Votes: 185
Popularity: 0.62
First Submitted: 2009-11-09 11:22 (UTC)
Last Updated: 2024-09-20 00:31 (UTC)

Pinned Comments

Refutationalist commented on 2024-05-22 22:08 (UTC) (edited on 2024-05-23 00:07 (UTC) by Refutationalist)

As of now (2024-22-05) Xen with stubdom doesn't build because of a problem in the imported code. Been this way for about two weeks. Anyone else seeing this behavior?

Also, there is a lot of work happening on Xen in my development repo, thanks to @Serus. Check it out at: https://github.com/refutationalist/saur

Latest Comments

« First ‹ Previous 1 .. 41 42 43 44 45 46 47 48 49 50 51 .. 101 Next › Last »

ArthurBorsboom commented on 2014-10-29 07:50 (UTC)

What is the impact of these changes on existing Xen installations?

zir_blazer commented on 2014-10-29 03:41 (UTC)

Just tested the new package yesterday, with good results. Using makepkg with the default PKGBUILD automatically downloads OVMF, builds it successfully, and after installing, it is ready to use as I could create an UEFI DomU showing TianoCore splash screen. Amazing work. I think that you're the first one to introduce OVMF support into a Xen package. I do expect that being default build option, some users may have fun trying to make a UEFI DomU for Windows 7/8 or Linux when they notice that support for OVMF is already included and ready to use. But there are some drawbacks. First, that maybe not everyone likes the 200 MiB download. It goes unnoticed when you have 20-30 mins compile time through, so seems minor. The other drawback is that because you're also downloading code from another repository, if for some reason something breaks on the OVMF side, the package will fail to build. Its potentially more work when that happens (Last time was with GCC 4.9 release). A more safe way could be by including a compiled OVMF Firmware in the package and invoking it with --with-system-ovmf=<path>, through I never managed to get it working that way. For as long as everything works, the current way rocks as you get the latest code. I didn't tested Xen UEFI Boot using binutils with x86_64-pep. However, I did recently a feature request for that to be included in default binutils: https://bugs.archlinux.org/task/42540 The sad part of all this is that I'm stuck with Xen 4.3 due to my regression issue, because as I use Xen for a gaming Windows VM, passthrough is a must. So besides testing to say that it works, I will not be able to enjoy it.

isiachi commented on 2014-10-28 14:17 (UTC)

I've just modified the 09_xen to add grub support to intel_ucode package. My version of 09_xen automatic detects the presence of /boot/intel-ucode.img and add it to grub.cfg. http://downloads.rhyeworld.it/files/static/isiachi/09_xen

kantras commented on 2014-10-28 00:51 (UTC)

@zir_blazer: Ok, was finally able to get the OVMF tree, which is pulled via git during compile, to compile. This new update should have this, along with some more cleanup as well as enabling spice support. Also, if binutils has been rebuilt with the correct option, it will detect the xen.efi file and will move it into /boot. An example xen.cfg is also included as /etc/xen/efi-xen.cfg - simply copy it over into /boot/xen.cfg and edit it with your options.

kantras commented on 2014-10-13 18:09 (UTC)

@zir_blazer: This is on my todo list (Last night I was actually going over the forum posts you had made previously) however I've not had a lot of spare time recently to sit down and work on this (as well as enabling spice support) I'm about to do a major overhaul on my primary desktop system (which uses the xen hypervisor) so was going to tackle that at the same time. I've also been watching your posts on xen-users and xen-devel, so am aware of it; i've not personally experienced those issues however my setup is a little different so wouldn't likely be hit by some of that (i.e I use a usb headset to my domU, rather than pass through sound)

zir_blazer commented on 2014-10-13 17:29 (UTC)

I would like to repeat my request for OVMF support, which allows to make DomUs with UEFI Firmware instead of BIOS. The idea is that by adding --enable-ovmf in the ./configure line, it automatically downloads 200 MiB or so from edk2 Source Repository and builds it to get a binary that is included with Xen, so you can later create a DomU with it: http://wiki.xen.org/wiki/OVMF While I didn't tried building with OVMF recently, the last time I attemped to do so, it fails to build cause the Source Code it downloads from edk2 repository isn't modified to build properly in Arch Linux (It isn't aware that python = Python 3.x and it has to use python2 instead, and it also had some issues with GCC 4.9). The other option for doing so, --with-system-ovmf=<ovmf.bin path> never worked for me either. The only success I had was when I merged the modified Source Code from the ovmf-svn package into the directory where xen downloads the edk2 source. Also, I repeated that procedure with the xen-4.3 package but I wasn't able to get OVMF working. Nor I tested with 4.4.1 to check if it still works. In other news, while toying around with Xen 4.4.1 I hit some nasty regressions in PCI and VGA Passthrough. The Sound Card works but produces tons of noise everytime that it reproduces a sound (Workaroundeable), and VGA Passthrough is a total no-go. Both things works fine if I try with the xen-4.3 package. Would like to know if anyone else that tested both 4.3.x and 4.4.1 had issues with Passthrough. More info here: http://lists.xen.org/archives/html/xen-devel/2014-10/msg00549.html Would like to know if other Passthrough users had issues or not between those two versions.

ArthurBorsboom commented on 2014-10-12 19:32 (UTC)

I hereby confirm that the Xen package on my server has upgraded successfully by my regular updating method using yaourt, from v4.4.0 to v4.4.1. Just a hint for other users, don't forget to update grub manually afterwards; this can save you a phone call to your service provider. (Whoooops) :D Thanks Kantras for analyzing and fixing.

kantras commented on 2014-10-12 09:20 (UTC)

Thanks to a log provided by ArthurBorsboom, I've been able to work out why some people were having build issues and the fix is applied in the new version I've just uploaded. As always, the change log should show all that has happen per new upload

hbc2 commented on 2014-10-11 08:51 (UTC)

@kantras I am able to install now. I'm unsure what I did differently this time around (even checked my past bash history). I think I was having mirror issue a couple weeks back. Thanks for your help.

kantras commented on 2014-10-03 21:25 (UTC)

I'm aware of it and will be uploading a new version once I've completed build-testing

« First ‹ Previous 1 .. 41 42 43 44 45 46 47 48 49 50 51 .. 101 Next › Last »