This is an ebuild to build and install the xen stubdom. It was a simple conversion of the pvgrub ebuild which may mean it is carrying conditional x86/amd64 code which isn't actually required. http://wiki.xen.org/wiki/Device_Model_Stub_Domains I have tested this on amd64 and successfully started hvm domains using with stubdom support. Reproducible: Always
Created attachment 331635 [details] New ebuild
I have uncovered one problem with stubdom networking. If two machines which are both running in a stubdom are trying to communicate you must use ethtool -K <vifname> tx off to make networking operate. ICMP between the two worked ok but TCP would fail. A bit of searching suggested that it is possible some checksum patches have not been ported to stubdom. (in my case the vms are on the same dom0 and connected to the same bridge)
Created attachment 331716 [details] New ebuild (update description, elog messages, remove multilib conditional code)
Hmm. interesting. Have just now completed upgrades to all xens, 4.2.0 && 4.2.1. I suggest you repeat the process modelling off the improved xen-pvgrub-4.2.1-r1, a 10 minute job really. Report it up and running and I shall see to adding it in due course
Created attachment 337688 [details] Ebuild update based on pv-grub 4.2.1-r1
New ebuild tested succesfully with Linux HVM amd64 guest on amd64 dom0.
yes the ebuild works and builds, however if use multilib; then multilib_toolchain_setup x86 emake XEN_TARGET_ARCH="x86_32" -C stubdom genpath ioemu-stubdom fi Point 1. I can't get it to build. Point 2. I'd have thought it would apply equally. No? I've tidies up a few trivialities. Once we sort the above it should be good to go.
(In reply to comment #7) > yes the ebuild works and builds, however > > if use multilib; then > multilib_toolchain_setup x86 > emake XEN_TARGET_ARCH="x86_32" -C stubdom genpath > ioemu-stubdom > fi > > Point 1. I can't get it to build. > Point 2. I'd have thought it would apply equally. No? I don't have a multilib dom0 so I can't test this however with my x86_64 build I can start 32- and 64-bit Windows XP guests. As far as I can tell there is no requirement for the stubdom to match the bitness of the guest it is supporting.
therefore it's not required, hence its absence, I take it
I shall add it soon when my system is doing commit 'properly'
This package is more apt to the virtual overlay for initial inclusion. Given you're perhaps the 1 and only user, it requires by rights further demonstrated demand to add to portage. repoman commit -m "[xen-stubdom] New package, ebuild written by 'spookyghost@blueyonder.co.uk', minor edits add to ebuild from recent inprovements from the parent package xen-stubdom, CC.patch added, source Bug #446241" Writing objects: 100% (8/8), 4.01 KiB, done. Total 8 (delta 0), reused 0 (delta 0) To git+ssh://git@git.overlays.gentoo.org/proj/virtualization 2d392cb..4c221e2 master -> master Need your name for the metadata.xm;
Real name? James Dingwall <james (at) dingwall (dot) me (dot) uk>
<james@dingwall.me.uk>. Eeer I think it loses something in the translation. Please view the edited metadata.xml and do tell is this to your liking, to my liking, none the above 'ere serve me up the next required correction. Thanks for the ebuild. ~/VirtualOverlay/app-emulation/xen-stubdom $ repoman commit -m "[xen-stubdom] Name of contributor added to metadata.xml" To git+ssh://git@git.overlays.gentoo.org/proj/virtualization 4c221e2..676e407 master -> master
(In reply to comment #13) > Please view the edited metadata.xml and do tell is this Fine with me
Added to virtualization overlay
