Summary: | app-emulation/xen-tools: bundles app-emulation/qemu | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Thomas Deutschmann (RETIRED) <whissi> |
Component: | Current packages | Assignee: | Gentoo Xen Devs <xen> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | ajak, arthur, esigra, hydrapolic, proxy-maint, sam, security, tamiko, virtualization, zlogene |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 251464 |
Description
Thomas Deutschmann (RETIRED)
2017-02-17 10:54:29 UTC
well, we've already provided the ability to unbundle the qemu, just we haven't make it default. if people like (also willing to take the risk), they can choose to build app-emulation/xen-tools with USE=system-qemu enabled (thus unbundle the internal qemu) but to your question, I'd still give a NO 1) there are two qemu device models in xen, a) qemu-traditional b) qemu-upstream qemu-traditiaonal is the old code base, we intend to kill it once but fail to do it, because some guest OS - windows VM? have problem to switch to new qemu-upstream once they already using the old (qemu-traditional) what you call *qemu unbundle* can only happen to b) .. so it won't benefit or cost us much to do it see [1] for more information 2) qemu and xen upstream has different release cycle.. currently we are only tracking the xen release version the xen-4.8.0 is actually using qemu-2.7.0 (xen-4.7.1 using 2.4.1), and we highly rely on xen upstream for the bug/security fixes, which mean upstream should guarantee xen-4.8.0 works fine with the bunbled qemu-2.7.0, on the other side, we can't guarantee if the app-emulation/xen/-tools-4.8.0 works with app-emulation/qemu (code may diverse, may break things, xen upstream didn't test the combination) [1] https://wiki.xenproject.org/wiki/QEMU_Upstream |