Package Base Details: xen

Git Clone URL: https://aur.archlinux.org/xen.git (read-only, click to copy)
Keywords: hypervisor virtualization xen
Submitter: sergej
Maintainer: Refutationalist
Last Packager: Refutationalist
Votes: 185
Popularity: 0.36
First Submitted: 2009-11-09 11:22 (UTC)
Last Updated: 2024-01-19 23:00 (UTC)

Latest Comments

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

3000 commented on 2013-01-03 08:29 (UTC)

hi, I somehow can't build this. I already have xen installed on another harddrive with Xen 4.2, but here I get this error message: /usr/bin/ld: vl.o: undefined reference to symbol 'timer_settime@@GLIBC_2.3.3' /usr/bin/ld: note: 'timer_settime@@GLIBC_2.3.3' is defined in DSO /usr/lib/librt .so.1 so try adding it to the linker command line /usr/lib/librt.so.1: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status make[4]: *** [qemu-dm] Error 1 make[4]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/tools/qem u-xen-traditional-dir/i386-dm' make[3]: *** [subdir-i386-dm] Error 2 make[3]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/tools/qem u-xen-traditional-dir' make[2]: *** [subdir-install-qemu-xen-traditional-dir] Error 2 make[2]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/tools' make[1]: *** [subdirs-install] Error 2 make[1]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/tools' make: *** [install-tools] Error 2 ==> ERROR: A failure occurred in package(). Aborting... ==> ERROR: Makepkg was unable to build xen. ==> Restart building xen ? [y/N] I get the same error display when I try to build from source. how can I fix this??

luolimao commented on 2012-12-19 03:58 (UTC)

Thanks, kantras; updated.

kantras commented on 2012-12-18 16:39 (UTC)

4.2.1 has been released. The exist PKGBUILD can be used (once the shasum's are updated) or I just uploaded a modified copy to http://www.kantras.info/xen/PKGBUILD (It also has a fix so that updates won't clobber the /etc/xen/xl.conf file.) I've just built the new version and have it running on a workstation.

<deleted-account> commented on 2012-12-16 10:19 (UTC)

Custom backend network device name seems not working. When I tried vif = ['ip=192.168.1,2, vifname=vif1.0, backend=networkvm'] in the client domU config file, the backend device in driver domain (networkvm) was named according to default vifDOMID.DEVID and not vif1.0 as specified in the script - resulting in different names every time I restarted the client domU. Any idea what could cause this strange behaviour?

kantras commented on 2012-11-25 21:03 (UTC)

You will also want to add "etc/$pkgname/xl.conf" to the backup section in the PKGBUILD file to avoid changes (such as to the ballooning settings) being clobbered during an upgrade. I also have a couple of template files for /etc/conf.d/xen{console,store}d if needed. Also, wondering it's worth making the name for dom0 to be definable via the conf file, defaulting to Domain-0 if nothing is explicitly set.

luolimao commented on 2012-11-22 18:16 (UTC)

Used tmpfiles method, and added the tmpfiles service to requires/after of xenstored.service

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'.