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.68
First Submitted: 2009-11-09 11:22 (UTC)
Last Updated: 2024-09-20 00:31 (UTC)

Dependencies (63)

Sources (7)

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 .. 76 77 78 79 80 81 82 83 84 85 86 .. 101 Next › Last »

paleo9 commented on 2012-11-22 15:14 (UTC)

'thinking aloud' You have demonstrated that the existence of /run/xen allows the module and its successors to load in your guest, which then runs successfully. kantras' tmpfiles.d/xen.conf will create that file, tmpfiles.d is usually used for temporary files created in /tmp or /run - fits the bill. Possible alternative: I have found in the old xencommons script 'mkdir -p /var/run/xen'. It is located before just before xenstored is started. So an equivalent ought to be the same line in ExecStartPre of xenstored.service. Could you try that? There exists systemd-tmpfiles but seems overkill for our purposes. tmpfiles is an established method used specifically for our purpose of creating '/run/xen'. The systemd service file method mimics the old xencommons way, attempting to create '/var/run/xen' @everybody: Any thoughts?

Refutationalist commented on 2012-11-22 13:06 (UTC)

@paleo9 What you are looking at *is* the initramfs loading up the xen_blkfront module in order to find its root. It can't find it's root because the socket which allows the PV to talk xen, which is supposed to exist in /run/xen. If you'll read the rest of the dump, I create said directory, and the PV loads instantly and without problems. Again: kantras' tmpfiles.d solution would appear to be the way to go and should be included.

paleo9 commented on 2012-11-22 12:42 (UTC)

@WaxyMouthfeel Welcome to Finnix! [*] Total memory: 2004MiB, shared ramdisk: 1591MiB [*] Setting up ramdisk... done [*] Loading probed module: [*] Loading probed module: xen_blkfront /* and here it freezes until I destroy the domain */ Xen is starting your pv, but the pv fails on startup when attempting to load xen_blkfront. Arch (for example) as a pv guest needs extra modules in its initramfs. The pv guest needs its initramfs image rebuilt with MODULES = "xen-blkfront xen-fbfront xen-netfront xen-kbdfront" in its /etc/mkinitramfs. Debian doesn't need this additional step to run as a pv guest. See https://wiki.archlinux.org/index.php/Xen#Installation_notes_for_domU_Paravirtualized_guests and 'Common Errors'.

kantras commented on 2012-11-22 04:34 (UTC)

I have a Windows 7 domU with an ATI 6770 passed through as a secondary adaptor, along with a USB 2.0 root hub and USB 3.0 root hub. Its been working well, except that I can't install the PV drivers without the ATI driver appearing to cause a blue screen on bootup. Still runs well without them. This is on a ASUS Sabertooth 990FX motherboard with an AMD Phenom II x4 965 processor and a total of 12Gb on board (6Gb assigned to the Windows domU)

aaronfitz commented on 2012-11-22 04:12 (UTC)

Just tried the new package and things seem to go much smoother. I had to create the folder /var/lib/xen/ by hand in order to create a HVM though. Based on the processor usage pattern after I start the HVM Windows 7 is starting, but I'm not getting any display through the video adapter I pass through to the HVM. I never got the dedicated graphics passthrough capability working on 4.1, the graphics was just passed through as a PCI device. Not sure what's going on with the PCI passthrough but I'll keep fiddling with my setup. Anyone here using this for PCI or GFX passthrough yet?

Refutationalist commented on 2012-11-22 01:54 (UTC)

Sorry to insist, but in some supported configurations /run/xen *is* needed: http://pastebin.com/QaqS2Krt kantras' tmpfiles.d solution would appear to be the way to go and should be included.

luolimao commented on 2012-11-21 22:54 (UTC)

fixed.

paleo9 commented on 2012-11-21 22:46 (UTC)

Just tried the modified xenstored.service, doesn't like it. This is the one: tested, works ExecStart=/usr/sbin/xenstored --pid-file /var/run/xenstored.pid $XENSTORED_ARGS ExecStartPost=/usr/bin/xenstore-write "/local/domain/0/name" "Domain-0" Result: Name ID Mem VCPUs State Time(s) Domain-0 0 1024 2 r----- 24.9

luolimao commented on 2012-11-21 21:50 (UTC)

Removed archinit.patch and added xenstore-write cmd to xenstored service file.

« First ‹ Previous 1 .. 76 77 78 79 80 81 82 83 84 85 86 .. 101 Next › Last »