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)

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 .. 79 80 81 82 83 84 85 86 87 88 89 .. 101 Next › Last »

Refutationalist commented on 2012-11-15 04:00 (UTC)

fernando_ccs17: You have to create /var/lib/xen as a directory. I've been working on that and some other build-time things.

fernando_ccs17 commented on 2012-11-15 02:26 (UTC)

[root@localhost fernando]# xl create xlexample.hvm Parsing config from xlexample.hvm xc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->000000000019dec8 TOTAL: 0000000000000000->0000000007800000 ENTRY ADDRESS: 0000000000100000 xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x000000000000003b 1GB PAGES: 0x0000000000000000 libxl: error: libxl_dom.c:1535:libxl_userdata_store: cannot write /var/lib/xen/userdata-n.3.77ea2db4-871e-4688-8d7e-f68c1a754b04.xl for /var/lib/xen/userdata-d.3.77ea2db4-871e-4688-8d7e-f68c1a754b04.xl: No such file or directory cannot save config file: No such file or directory libxl: error: libxl_dom.c:1462:libxl__userdata_destroyall: glob failed for /var/lib/xen/userdata-?.3.77ea2db4-871e-4688-8d7e-f68c1a754b04.*: No such file or directory *** the "xen" folder in /var/lib/ does not exist. only "xenstored" exist there. *** content of xlexample.hvm: builder = "hvm" name = "example.hvm" memory = 128 vcpus = 1 vnc = 1

paleo9 commented on 2012-11-12 18:34 (UTC)

I have never used libvirt, and I do not have a hardware-virtual processor (nor any need for one), so anything I can do will be limited to pv. I have just downloaded v1.0.0 and made an initial attempt to build it. I am also checking out the abs build. However, even if it builds, it may not have all features. http://wiki.xen.org/wiki/Fedora_Host_Installation "Starting from Xen 4.2, the default toolstack is libxl. libvirt has a libxl driver, but it (at the time of writing) still lacks many important features... ...There is an on-going effort to fill the gap and render the libvirt libxl driver feature complete and fully functional, although it is yet unclear when that will happen (in particular, whether or not it will make it in time for Fedora 18." On the other hand, the tarball that I downloaded (stable libvirt 1.0.0) has News November 2 2012 at least mentions xen 4.2. So there may be hope. http://libvirt.org/news.html "various improvement and fixes when using QMP QEmu interface Support for Xen 4.2 (Jim Fehlig)" If I have anything more useful to say, I shall put it on some libvirt page and leave a comment here.

loper commented on 2012-11-11 23:09 (UTC)

@ paleo9: thanks, running # xenstore-write "/local/domain/0/name" "Domain-0" manually changed the (null) value. Is there any way to get libvirt for xen to build without error?

kantras commented on 2012-11-11 19:13 (UTC)

Writing something to add the name into xenstore (amongst other things, such as using xl to update my assignable pci devices) is on my todo list; right now I just kick off script on bootup, but that won't work for me once I start using xendomains to auto-start. @fernando_ccs17, my desktop has both an ATI and a Nvidia graphics card in it, and I spend a few hours trying to get the official Nvidia drivers working, only to have to give up for now. The problem is that Nvidia have already stated that they will only support the Quadro series when it comes to virtualization, so i'm waiting for nouveau support to improve. The ATI card, which is passed through to a Windows domU, works much better (although still with quirks at times)

paleo9 commented on 2012-11-11 15:04 (UTC)

Re "Domain-0" and (null), the relevant lines in xencommons are: echo Setting domain 0 name... xenstore-write "/local/domain/0/name" "Domain-0" My thoughts: It appears to be using "xenstore-write" to place an entry "Domain-0" into the 'name' field of its database. There is only one dom0, so there should not be a "/local/domain/1/name" or "Domain-1" etc. It is unlikely that there will be anything to be gained by checking the value of "/local/domain/0/name/", so unless errors happen it was not a high priority for getting the service file to work.

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

Nothing to worry about. In the old xencommons script, which has been replaced by systemd service files, there was a line which gave the name Domain-0. Can't remember off hand, maybe printed a line into the pid file? Anyway, this line wasn't included in the service file. It's not used by anything, just a label for human eyes.

loper commented on 2012-11-11 14:04 (UTC)

any idea why am I having (null) instead of Domain-0?