New version released! http://wiki.xenproject.org/wiki/Xen_4.3_Release_Notes Reproducible: Always
right xen-tools-4.3.0. is in to kick things off. Please give it a run and a comment. I've covered important basics at this point.
(In reply to Ian Delaney from comment #1) > right xen-tools-4.3.0. is in to kick things off. > Please give it a run and a comment. I've covered important basics at this > point. Please revise the xend init script. So far, I have not been able to switch from xm to xl (it simply doesn't work for me, for some reason. And the xen developers have not been a big help so far). The xend init scripts uses the opts variable, which is deprecated for a while now. I haven't done much testing otherwise. Even simply things like "xl dmesg" or "xm dmesg" fail with "Permission denied" or "Is xend running?" respectively. (And yes, xend is running.) Maybe these things would work after the hypervisor is upgraded to 4.3?
right; *xen-4.3.0 (21 Jul 2013) 21 Jul 2013; Ian Delaney <idella4@gentoo.org> +files/xen-4.3-fix_dotconfig-gcc.patch, +xen-4.3.0.ebuild: bump; Removed py2.6 by discretion, added upgraded patch, all sec patches dropped (now inc. in source) *xen-pvgrub-4.3.0 (21 Jul 2013) 21 Jul 2013; Ian Delaney <idella4@gentoo.org> +files/xen-4.3-externals.patch, +files/xen-4.3-fix_dotconfig-gcc.patch, +xen-pvgrub-4.3.0.ebuild: bump; Cull redundant sec. patches, upgrade 2 patches, add 1 new DEP and and 1 new external package
I used two use flags before: hvm qemu, and using these emerge xen-tools fail. Interesting, it fails in the isntall part, it complains about missing the usr/lib/xen/bin/vssclient (it's not in the /var/tmp/portage/.../image...). In fact: Although I used these use flags before: 1: I didn't even tried any hvm domu. 2: I used the "upstream qemu?" (installed the qemu package and using these options in the domu config: device_model_version = 'qemu-xen' device_model_override = '/usr/bin/qemu-system-x86_64' (because the qemu distributed with the Xen is really old, and the memory leak not fixed in the 4.2.2 either (I didn't check the 4.3.0 yet, but in fact I don't care anymore). Without the hvm, qemu use flags (in fact, i disabled ALL use flags) xen and xen-tools installs fine, I use 3.10.1 kernel for both dom0 and domu, and use a mysql server for production in it (a backup replication at the moment), and it seems to work fine. I see two problems here: 1: with qemu use flag, xen-tools not install. 2: BUT is disabled, maybe the default device_model_... executable should be the upstream qemu one. In fact I don't understand the meaning of qemu USE flag in general.
(In reply to László Szalma from comment #4) > I used two use flags before: hvm qemu, and using these emerge xen-tools > fail. Interesting, it fails in the isntall part, it complains about missing > the usr/lib/xen/bin/vssclient (it's not in the > /var/tmp/portage/.../image...). In fact: > > I see two problems here: > > 1: with qemu use flag, xen-tools not install. > 2: BUT is disabled, maybe the default device_model_... executable should be > the upstream qemu one. > > In fact I don't understand the meaning of qemu USE flag in general. vssclient is a mis-spelling. It's vscclient, it's a new file installed with USE hvm qemu. > "it fails in the (install) part."> Is this install phase of the ebuild or installing to the system install, they're two entirely separate phases. If the latter, this indicates it's possibly seeking an already installed usr/lib/xen/bin/vscclient, but I doubt it. If you observe within the ebuild, xensource attempts to install it to /usr/lib/...., but I re-direct it to /usr/lib64/ (if arch is amd64) otherwise it's correct for x86. This shouldn't be a problem.
(In reply to László Szalma from comment #4) > In fact I don't understand the meaning of qemu USE flag in general. if use qemu; then export "CONFIG_IOEMU=y" This is the fundamental impact of use qemu. This makes the build of xen-tools qemu (and hvm) capable. < (because the qemu distributed with the Xen is really old, and the memory leak not fixed in the 4.2.2 either > The main feature of the xensource is the presence and prevalence of external packages. It comes with qemu in place under the tools folder. Since this is done by the xen developers, they equip it at their own hand to do the job. Installing an alternate newer qemu package leads to possibly trying to fit square pegs in round holes. Note; files/xen-tools-4.2-xen_disk_leak.patch A patch to address the memory leak.
(In reply to Ian Delaney from comment #6) > job. Installing an alternate newer qemu package leads to possibly trying to > fit square pegs in round holes. :D I like the metaphor! But in fact, I see problems with the one in the source package, and none with the external... > > Note; > files/xen-tools-4.2-xen_disk_leak.patch > A patch to address the memory leak. This is what I'm talking about. This fix is not included for ages, I don't think I was the only one affected. I'm not talking about Gentoo, but in general. Strange. I think most is the users, and package maintainers use external qemu, or apply these patches by hand.
I have upgraded to xen-4.3 and xen-tools-4.3 now. I only use paravirtualized domUs. Both dom0 and domUs run kernel 3.10.1. They run fine. No problems at all. Thanks for adding 4.3 to the tree. (In reply to László Szalma from comment #4) > device_model_version = 'qemu-xen' > device_model_override = '/usr/bin/qemu-system-x86_64' I read that Xen 4.3 has switched to upstream qemu for most domUs by default. Some types still require the Xen qemu.
> vssclient is a mis-spelling. It's vscclient, it's a new file installed with > USE hvm qemu. > > "it fails in the (install) part."> Is this install phase of the ebuild or installing to the system install, they're two entirely separate phases. If the latter, this indicates it's possibly seeking an already installed usr/lib/xen/bin/vscclient, but I doubt it. If you observe within the ebuild, xensource attempts to install it to /usr/lib/...., but I re-direct it to /usr/lib64/ (if arch is amd64) otherwise it's correct for x86. This shouldn't be a problem. Sorry, I mis-spelled only when I wrote it here. Anyway, the file really not exists: * Fixing shebang in usr/lib64/python2.7/site-packages/xen/xm/xenapi_create.py * Fixing shebang in usr/lib64/python2.7/site-packages/xen/remus/save.py * Fixing shebang in usr/lib64/python2.7/site-packages/xen/remus/vm.py mv: cannot stat ‘/var/tmp/portage/app-emulation/xen-tools-4.3.0/image/usr/lib/xen/bin/vscclient’: No such file or directory * ERROR: app-emulation/xen-tools-4.3.0 failed (install phase): * (no error message) * * Call stack: * ebuild.sh, line 93: Called src_install * environment, line 3225: Called die * The specific snippet of code: * mv "${D}"usr/lib/xen/bin/{qemu*,vscclient,virtfs-proxy-helper} "${D}"usr/$(get_libdir)/xen/bin/ || die; * # ls -l /var/tmp/portage/app-emulation/xen-tools-4.3.0/image/usr/lib/xen/bin/ total 92 -rwxr-xr-x 1 root root 91388 júl 21 21:09 xenpaging No other files here. I think I can't help with this one, because the problem not affecting me at the moment, and I don't even know this vscclient thing at all. But I think the actual ebuild doesn't work with these USE flags ATM, and I don't know if it affects others. The ebuild assumes the build of the vscclient binary (and virtfs-proxy-helper binary too, which is missing too). I don't know if they should be built, or be built by other USE flags, or they aren't needed in 4.3.0 at all... This one is in the src_install() of the ebuild (line 292 in the actual version) This line is changed in 4.3.0, does it build fine for you? I attach the build log, perhaps it helps.
Created attachment 353784 [details] xen-tools_hvm_qemu_amd64_build.log build.log when USE="qemu hvm" on amd64.
app-emulation/xen-tools $ ls -ld /mnt/gen2/TmpDir/portage/app-emulation/xen-tools-4.3.0/image/usr/lib64/xen/bin/{vscclient,virtfs-proxy-helper} -rwxr-xr-x 1 testuser testuser 34872 Jul 22 13:18 /mnt/gen2/TmpDir/portage/app-emulation/xen-tools-4.3.0/image/usr/lib64/xen/bin/virtfs-proxy-helper -rwxr-xr-x 1 testuser testuser 71640 Jul 22 13:18 /mnt/gen2/TmpDir/portage/app-emulation/xen-tools-4.3.0/image/usr/lib64/xen/bin/vscclient Anyway, this bug is finished being a version bump. On closing it appears your xen-tools-4.3.0/image/usr/lib64/xen/bin/{vscclient,virtfs-proxy-helper} are NOT being built, which may well be a square peg. I'm guessing you have the upstream qemu package installed.
