On Mon, Mar 20, 2017 at 03:27:19PM +0800, yonglihe wrote:
tested v3, on the mdev-next branch:
none-root:
======
1. hacker the privilege operations
sudo sh -c "ulimit -l 3074424832 && exec su $LOGNAME"
sudo chown ubuntu:ubuntu /dev/vfio/0
RFC: i don't know the correct way to do such thing while build it from
sources. updated me, thanks.
I'm not sure what you're referring to, so could you be more specific, so we can
work from there and find the right solution?
[...]
rooted mode
========
start libvirt-d trace:
--------------------------
this trace shows occasionally while starting the libvirt-d, not every time.
2017-03-19 19:22:45.559+0000: 13104: info : libvirt version: 3.2.0
2017-03-19 19:22:45.559+0000: 13104: info : hostname: z-nuc-11.maas
2017-03-19 19:22:45.559+0000: 13104: error : qemuMonitorOpenUnix:367 :
failed to connect to monitor socket: No such process
2017-03-19 19:22:45.562+0000: 13000: info : libvirt version: 3.2.0
2017-03-19 19:22:45.562+0000: 13000: info : hostname: z-nuc-11.maas
2017-03-19 19:22:45.562+0000: 13000: error : virNetSocketReadWire:1800 : End
of file while reading data: Input/output error
Hmm, the virNetSocketReadWire might go away with the recent libvirt patches (I
rebased my branch onto current master) if you're using either virtlogd (which
is the default in qemu.conf on RHEL if I'm not mistaken) or virtlockd, so try
with the rebased branch. But I doubt the qemuMonitorOpenUnix bit would
disappear with the mentioned libvirt fix. But I will need a fresh and complete
daemon log to investigate further, as well as libvirtd.conf and qemu.conf (just
in case), so that I can compare to my environment, since I'm not able to
reproduce this.
[...]
NOTES:
there is no traces under none root mode, though i don't think the trace
is related to user privilege. fix me.
It's indeed odd that you don't see the same behaviour when running qemu as
root. As I said, I will need the daemon log and preferably the configs as well
to investigate further.
Thanks,
Erik