On Oct 3, 2015, at 20:48 , Martin Polednik <mpolednik(a)redhat.com&gt; wrote: > Hello everyone, > > I've been reworking the fake_kvm and faqemu VDSM hook to make them > somewhat more usable and mostly to allow testing of ppc64le on x86_64 > based hosts. > > TL;DR version: checkout [1], enable fake_kvm and happy ppc64le hacking :) > > Current fake_kvm isn't really a hook and is contained within 'caps' > module. This is wrong for multiple reasons, the most important one > being mixing optional with mainline code. Another issue appears when > one tries to move the fake_kvm code into a hook: the whole notion of > architectures within VDSM is contained within the 'caps' module. > > The patch series, which git tip is at [1], introduces new cpuinfo > module that moves information related to architecture to 'cpuinfo' > module of the VDSM library. Intermediate benefit is that current hooks > and library code can access the information related to host's cpu. > > This allows for moving fake_kvm code into a hook that I've called > fakearch. Fakearch is, in my opinion, more suitable name - there is > barely any KVM faking, but the host 'fakes' selected architecture. > > Faqemu is, on the other hand, a hook. Unfortunately it wasn't really > updated and doesn't allow running VMs under fake architecture. The > series therefore try to refactor it to allow cross-arch VMs to be > started (the VM actually uses host architecture, but from engine's > point of view it's running on the faked arch). so it will run in full emulation, or?

> > So far tested cross-arch runs are * x86_64->x86_64 (faqemu functionality), > * x86_64->ppc64le (the most important one), > * ppc64le->x86_64, > * ppc64le->ppc64le (faqemu for Power). > > I'm interested in your reviews and comments regarding this effort! > > [1] https://gerrit.ovirt.org/#/c/46962/ > > Best regards, > mpolednik

On 26 Oct 2015, at 09:41, Dan Kenigsberg <danken(a)redhat.com&gt; wrote: On Mon, Oct 05, 2015 at 02:53:00PM +0200, Martin Polednik wrote: > On 05/10/15 11:31 +0200, Michal Skrivanek wrote: >> >> On Oct 3, 2015, at 20:48 , Martin Polednik <mpolednik(a)redhat.com&gt; wrote: >> >>> Hello everyone, >>> >>> I've been reworking the fake_kvm and faqemu VDSM hook to make them >>> somewhat more usable and mostly to allow testing of ppc64le on x86_64 >>> based hosts. >>> >>> TL;DR version: checkout [1], enable fake_kvm and happy ppc64le hacking :) I like the initiative and the approach. Dropping faqemu bits out of mainline caps.py was an old task of mine. Moving code into lib/vdsm is a big task for our next release anyway.

>>> >>> Current fake_kvm isn't really a hook and is contained within 'caps' >>> module. This is wrong for multiple reasons, the most important one >>> being mixing optional with mainline code. Another issue appears when >>> one tries to move the fake_kvm code into a hook: the whole notion of >>> architectures within VDSM is contained within the 'caps' module. >>> >>> The patch series, which git tip is at [1], introduces new cpuinfo >>> module that moves information related to architecture to 'cpuinfo' >>> module of the VDSM library. Intermediate benefit is that current hooks >>> and library code can access the information related to host's cpu. >>> >>> This allows for moving fake_kvm code into a hook that I've called >>> fakearch. Fakearch is, in my opinion, more suitable name - there is >>> barely any KVM faking, but the host 'fakes' selected architecture. >>> >>> Faqemu is, on the other hand, a hook. Unfortunately it wasn't really >>> updated and doesn't allow running VMs under fake architecture. The >>> series therefore try to refactor it to allow cross-arch VMs to be >>> started (the VM actually uses host architecture, but from engine's >>> point of view it's running on the faked arch). >> >> so it will run in full emulation, or? > > That is tricky to answer. It is running full emulation in host's > architecture, hiding the differences between x86_64 and ppc64le by > modifying the XML e.g. spice->vnc when running x86_64 fakearch on > ppc64le host. > > The reason for that is the qemu-kvm-rhev doesn't seem to support > emulation of different arch, so the hook tries to 'fake' it. > > The implication is the fact that the underlying (libvirt) VM is quite > different to from what we ask for. I wouldn't recommend doing anything > with the VM apart from running it and killing it. It is called "fake" for a good reason. It should never be used for anything but to fake the existence of a VM to the rest of oVirt. ... which leads me to one tiny comment: I like the name faqemu. I don't see a real need for establishing a new hook with a new name. > >> >>> >>> So far tested cross-arch runs are * x86_64->x86_64 (faqemu functionality), >>> * x86_64->ppc64le (the most important one), >>> * ppc64le->x86_64, >>> * ppc64le->ppc64le (faqemu for Power). >>> >>> I'm interested in your reviews and comments regarding this effort! >>> >>> [1] https://gerrit.ovirt.org/#/c/46962/

On Mon, Oct 26, 2015 at 11:17:10AM +0100, Michal Skrivanek wrote: > > > On 26 Oct 2015, at 09:41, Dan Kenigsberg <danken(a)redhat.com&gt; wrote: > > > > On Mon, Oct 05, 2015 at 02:53:00PM +0200, Martin Polednik wrote: > >> On 05/10/15 11:31 +0200, Michal Skrivanek wrote: > >>> > >>> On Oct 3, 2015, at 20:48 , Martin Polednik <mpolednik(a)redhat.com&gt; wrote: > >>> > >>>> Hello everyone, > >>>> > >>>> I've been reworking the fake_kvm and faqemu VDSM hook to make them > >>>> somewhat more usable and mostly to allow testing of ppc64le on x86_64 > >>>> based hosts. > >>>> > >>>> TL;DR version: checkout [1], enable fake_kvm and happy ppc64le hacking :) > > > > I like the initiative and the approach. Dropping faqemu bits out of > > mainline caps.py was an old task of mine. Moving code into lib/vdsm is a > > big task for our next release anyway. > > one more unrelated note > current faqemu is broken on 3.6 as it removes the whole cpu tag which is needed when hotplug memory is enabled, which in turn enables numa, libvirt checks for cpu-numa mapping and fails to find any > please fix it along the way:-) Better fix it on its own, since we'd need to have the fix backported. (unless you plan to backport the whole cpuinfo branch)