Bug 1371223

Not sure what is the right product/component for this bug, but certainly not ovirt-engine-cli, that is only for the oVirt Engine command line interface. Can you explain where did you find this issue? In oVirt? in Red Hat Virtualization?

yes, sorry, indeed, there was nothing qemu related on the list thus I thought "core" it should be.
I use oVirt yum repos and qemu-kvm-ev comes from there.

Is there a reson this device-driver was excluded?
One last thing, where do we find .src.rpm packages? I'll say having sources in yum repos would help users help devel, I think it's a serious oversight not to put them in repos.

Sandro, any idea of what is the right person/product/component for this bug?

(In reply to lejeczek from comment #2)
> yes, sorry, indeed, there was nothing qemu related on the list thus I
> thought "core" it should be.
> I use oVirt yum repos and qemu-kvm-ev comes from there.
> 
> Is there a reson this device-driver was excluded?

We've never had a use case for it, so we did not use it. What is the use case?

> One last thing, where do we find .src.rpm packages? I'll say having sources
> in yum repos would help users help devel, I think it's a serious oversight
> not to put them in repos.

sorry, I'm not certain why you mean - use case - it seems mainstream approved, fedora's qemu has it.

well, the fact qemu has it does not mean it makes to use it from ovirt standpoint. So what is the scenario in which you would use it? How would it help you?

pass host's filesystem, its parts, to guests. I thought many used it. I see official kernels do not include modules just yet but kernels we can find in elrepo(and alternatives) have it. I think it would be great to have now, just a way to test for next versions of RHELs

(In reply to lejeczek from comment #7)
> pass host's filesystem, its parts, to guests. I thought many used it. I see
> official kernels do not include modules just yet but kernels we can find in
> elrepo(and alternatives) have it. I think it would be great to have now,
> just a way to test for next versions of RHELs

It is not in RHEV's qemu-kvm-rhev which oVirt's qemu-kvm-ev is based on. We do not do any modification to the package, it is just rebuilt. Once virtio-9p-pci is included in qemu-kvm-rhev(i.e. when it is no longer being blacklisted) oVirt will have it as well - well, the hypervisor support only, obviously it would need some work to add it to UI of oVirt as well afterwards. 
Generally all QEMU functionality which are not deemed stable or properly tested is removed in RHEV. Feel free to request such a change through the RHEV product

Alternatively you can use oVirt on Fedora with Fedora's qemu-kvm which has it all (with all the unstable bits)

you can see details of the qemu-kvm-rhev side in bug 1121780, hopefully we will get it eventually

There are two main issues with 9p:

- driver support for guest operating systems. This is basically non-existant for any guest other than modern Linux. It is a lot of work to address that problem.  For ad-hoc user file sharing between host + guest, we are working on a USB device supporting the MTP protocol.  Upstream work on virtio-vsock is also in progress, which would allow you to use nfs over vsock in the guest (and nfsd over vsock in the host).

- virtio-9p-pci is hard to configure in a secure manner, and the defaults are not secure.  As far as I know it has never been audited and the fact that it includes a setuid binary is not reassuring either.  The simplest security model is pretty much okay, but it only allows the guest to access files that QEMU is permitted to access on host (with the host's uid/gid values) and only allows the guest to create files with QEMU's uid/gid.  This is somewhat useful for libvirt's qemu:///session URI but not for qemu:///system, which is what oVirt uses and which confines QEMU to the "qemu" user and group.