Martin Kletzander
2017-Jun-06 08:43 UTC
Re: [libvirt-users] libvirtd not accepting connections
On Mon, Jun 05, 2017 at 07:52:58PM -0400, Michael C Cambria wrote:> > >On 06/05/2017 10:46 AM, Martin Kletzander wrote: >> On Sun, Jun 04, 2017 at 06:42:39PM -0400, Michael C Cambria wrote: >>> I've upgraded from Fedora 20; probably missed a merge of rpmnew with >>> existing .conf; permission problem, some other mistake along the way to >>> Fedora 25. >>> >> >> Yeah, probably some 'rpm -qV' (or whatever the command to verify all >> packages is) could help as well. > >"rpm -aV" didn't turn up anything obvious: > >S.5....T. c /etc/libvirt/libvirtd.conf was modified for logging: ># diff libvirtd.conf libvirtd.conf.rpmnew >1,4d0 >< log_level = 1 >< log_filters="1:remote 1:event 1:json 1:rpc 1:qemu" >< log_outputs="1:file:/var/log/libvirt/libvirtd.log" >< # ># > >>> Is there a "how to" similar to [1] that lets one qemu to log that it was >>> invoked and how far it got? >>> >>> I removed qemu (dnf remote qemu; sudo dnf remove qemu-common) >>> build qemu 2.2-maint (assuming this relates to 2:2.7.1-6.fc25) from >>> github sources >>> installed qemu from sources (into /usr/local/bin) >>> >>> Things are a bit better. Where something like "sudo virsh pool-list" >>> would just hang before, now my storage pools actually are listed. No >>> luck listing my VM's, but "virsh list" and "virsh list --all" do not >>> hang like before: >>> >>> # virsh list >> >> Are you sure you didn't miss the --all? >> >Yes I'm sure. I wish that was all it was <g> > >>> Id Name State >>> ---------------------------------------------------- >>> >>> # virsh pool-list >>> Name State Autostart >>> ------------------------------------------- >>> default active yes >>> Downloads active yes >>> guest_images_lvm active yes >>> >>> # >>> >>> VM xml is /etc/libvirt/qemu. The network, virbr0 is in >>> /etc/libvirt/qemu/networks, and that gets created just fine. All have >>> root:root owner:group: >>> >> >> The VMs are not visible because the XML cannot be parsed if the binaries >> are not on the system (the XML contains the whole path). Also, I think >> this works because libvirt doesn't look into /usr/local/bin, but I might >> be wrong. Check whether 'virsh capabilities' tells you something about >> any emulator. >> >> You can try installing from source, but putting it in /usr/bin, > > >I put qemu-system-x86_64 and qemu-x86_64 in /usr/bin as requested. No >luck. It seems /usr/local/bin/qemu-xxx is found (see CGroup: output) > >$ sudo systemctl status libvirtd.service >● libvirtd.service - Virtualization daemon > Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; >vendor preset: enabled) > Active: active (running) since Mon 2017-06-05 18:21:20 EDT; 3s ago > Docs: man:libvirtd(8) > http://libvirt.org > Main PID: 7076 (libvirtd) > Tasks: 19 (limit: 4915) > Memory: 124.7M > CPU: 3.649s > CGroup: /system.slice/libvirtd.service > ├─7076 /usr/sbin/libvirtd > └─7208 /usr/local/bin/qemu-system-sh4eb -S -no-user-config >-nodefaults -nographic -M none -qmp >unix:/var/lib/libvirt/qemu/capabilities.monitor.sock,server,nowait >-pidfile /var/lib/libvirt/qemu/capabi >So this is now only with the qemu from source installed on the system?>$ sudo virsh list --all > Id Name State >---------------------------------------------------- > >$ sudo virsh pool-list > Name State Autostart >------------------------------------------- > default active yes > Downloads active yes > guest_images_lvm active yes > >$ > >> you can >> also remove that installation, put back the one from the package and try >> running: >> >> { for i in qmp_capabilities query-commands quit; do echo >> "{'execute':'$i'}"; done } | qemu-system-x86_64 -nographic -nodefaults >> -no-user-config -M none -qmp stdio >> >> And see whether the QEMU process quits, what it outputs and if it gets >> stuck, you can attach gdb and see what it's waiting for. Or maybe try >> running it with strace. > >This completed almost instantly. >And that is with the QEMU installed form the package, right?>> You can also do a thing I used to do a lot. You can rename >> /usr/bin/qemu-system-x86_64 (for example) and create a script with that >> filename that for example execs as qemu in strace with the output of >> strace put in some file, or similar. I can't think of anything else for >> now, sorry. > >I'll try this ASAP. First I'll look at all the QEMU_MONITOR_* log >entries that contain "error" that I *am* getting with qemu installed >from source (in /usr/local/bin/qemu-*) > >2017-06-05 23:06:39.884+0000: 15559: info : >virEventPollDispatchHandles:506 : EVENT_POLL_DISPATCH_HANDLE: watch=11 >events=1 >2017-06-05 23:06:39.884+0000: 15559: info : virObjectRef:296 : >OBJECT_REF: obj=0x7f0a603d33b0 >2017-06-05 23:06:39.884+0000: 15559: info : qemuMonitorIOProcess:429 : >QEMU_MONITOR_IO_PROCESS: mon=0x7f0a603d33b0 buf={"id": "libvirt-41", >"error": {"class": "GenericError", "desc": "this feature or command is >not currently supported"}}^M > len=120Well, at least QEMU_MONITOR_ messages are showing, finally. The non-x86 machines might be missing lot of commands that libvirt needs. Like 'query-commands' which we need to know which commands we can run (bit of a catch 22 right there). But these should not happen with x86, x86_64, arm, arm64 (or aarch64), and few others. Those are being maintained continuously.>2017-06-05 23:06:39.884+0000: 15559: debug : >qemuMonitorJSONIOProcessLine:191 : Line [{"id": "libvirt-41", "error": >{"class": "GenericError", "desc": "this feature or command is not >currently supported"}}] >2017-06-05 23:06:39.884+0000: 15559: debug : virJSONValueFromString:1604 >: string={"id": "libvirt-41", "error": {"class": "GenericError", "desc": >"this feature or command is not currently supported"}} >2017-06-05 23:06:39.884+0000: 15559: debug : >virJSONParserHandleStartMap:1478 : parser=0x7ffe4440afd0 > > >> Have a nice day, >> Martin >> >Thank you, you too! > > >_______________________________________________ >libvirt-users mailing list >libvirt-users@redhat.com >https://www.redhat.com/mailman/listinfo/libvirt-users
Michael C. Cambria
2017-Jun-06 12:17 UTC
Re: [libvirt-users] libvirtd not accepting connections
On 06/06/2017 04:43 AM, Martin Kletzander wrote:> On Mon, Jun 05, 2017 at 07:52:58PM -0400, Michael C Cambria wrote: >> >> >> On 06/05/2017 10:46 AM, Martin Kletzander wrote: >>> On Sun, Jun 04, 2017 at 06:42:39PM -0400, Michael C Cambria wrote: >>>> I've upgraded from Fedora 20; probably missed a merge of rpmnew with >>>> existing .conf; permission problem, some other mistake along the >>>> way to >>>> Fedora 25. >>>> >>> >>> Yeah, probably some 'rpm -qV' (or whatever the command to verify all >>> packages is) could help as well. >> >> "rpm -aV" didn't turn up anything obvious: >> >> S.5....T. c /etc/libvirt/libvirtd.conf was modified for logging: >> # diff libvirtd.conf libvirtd.conf.rpmnew >> 1,4d0 >> < log_level = 1 >> < log_filters="1:remote 1:event 1:json 1:rpc 1:qemu" >> < log_outputs="1:file:/var/log/libvirt/libvirtd.log" >> < # >> # >> >>>> Is there a "how to" similar to [1] that lets one qemu to log that >>>> it was >>>> invoked and how far it got? >>>> >>>> I removed qemu (dnf remote qemu; sudo dnf remove qemu-common) >>>> build qemu 2.2-maint (assuming this relates to 2:2.7.1-6.fc25) from >>>> github sources >>>> installed qemu from sources (into /usr/local/bin) >>>> >>>> Things are a bit better. Where something like "sudo virsh pool-list" >>>> would just hang before, now my storage pools actually are listed. No >>>> luck listing my VM's, but "virsh list" and "virsh list --all" do not >>>> hang like before: >>>> >>>> # virsh list >>> >>> Are you sure you didn't miss the --all? >>> >> Yes I'm sure. I wish that was all it was <g> >> >>>> Id Name State >>>> ---------------------------------------------------- >>>> >>>> # virsh pool-list >>>> Name State Autostart >>>> ------------------------------------------- >>>> default active yes >>>> Downloads active yes >>>> guest_images_lvm active yes >>>> >>>> # >>>> >>>> VM xml is /etc/libvirt/qemu. The network, virbr0 is in >>>> /etc/libvirt/qemu/networks, and that gets created just fine. All have >>>> root:root owner:group: >>>> >>> >>> The VMs are not visible because the XML cannot be parsed if the >>> binaries >>> are not on the system (the XML contains the whole path). Also, I think >>> this works because libvirt doesn't look into /usr/local/bin, but I >>> might >>> be wrong. Check whether 'virsh capabilities' tells you something about >>> any emulator. >>> >>> You can try installing from source, but putting it in /usr/bin, >> >> >> I put qemu-system-x86_64 and qemu-x86_64 in /usr/bin as requested. No >> luck. It seems /usr/local/bin/qemu-xxx is found (see CGroup: output) >> >> $ sudo systemctl status libvirtd.service >> ● libvirtd.service - Virtualization daemon >> Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; >> vendor preset: enabled) >> Active: active (running) since Mon 2017-06-05 18:21:20 EDT; 3s ago >> Docs: man:libvirtd(8) >> http://libvirt.org >> Main PID: 7076 (libvirtd) >> Tasks: 19 (limit: 4915) >> Memory: 124.7M >> CPU: 3.649s >> CGroup: /system.slice/libvirtd.service >> ├─7076 /usr/sbin/libvirtd >> └─7208 /usr/local/bin/qemu-system-sh4eb -S -no-user-config >> -nodefaults -nographic -M none -qmp >> unix:/var/lib/libvirt/qemu/capabilities.monitor.sock,server,nowait >> -pidfile /var/lib/libvirt/qemu/capabi >> > > So this is now only with the qemu from source installed on the system?Correct.> >> $ sudo virsh list --all >> Id Name State >> ---------------------------------------------------- >> >> $ sudo virsh pool-list >> Name State Autostart >> ------------------------------------------- >> default active yes >> Downloads active yes >> guest_images_lvm active yes >> >> $ >> >>> you can >>> also remove that installation, put back the one from the package and >>> try >>> running: >>> >>> { for i in qmp_capabilities query-commands quit; do echo >>> "{'execute':'$i'}"; done } | qemu-system-x86_64 -nographic -nodefaults >>> -no-user-config -M none -qmp stdio >>> >>> And see whether the QEMU process quits, what it outputs and if it gets >>> stuck, you can attach gdb and see what it's waiting for. Or maybe try >>> running it with strace. >> >> This completed almost instantly. >> > > And that is with the QEMU installed form the package, right?Correct> >>> You can also do a thing I used to do a lot. You can rename >>> /usr/bin/qemu-system-x86_64 (for example) and create a script with that >>> filename that for example execs as qemu in strace with the output of >>> strace put in some file, or similar. I can't think of anything else >>> for >>> now, sorry. >> >> I'll try this ASAP. First I'll look at all the QEMU_MONITOR_* log >> entries that contain "error" that I *am* getting with qemu installed >> from source (in /usr/local/bin/qemu-*) >> >> 2017-06-05 23:06:39.884+0000: 15559: info : >> virEventPollDispatchHandles:506 : EVENT_POLL_DISPATCH_HANDLE: watch=11 >> events=1 >> 2017-06-05 23:06:39.884+0000: 15559: info : virObjectRef:296 : >> OBJECT_REF: obj=0x7f0a603d33b0 >> 2017-06-05 23:06:39.884+0000: 15559: info : qemuMonitorIOProcess:429 : >> QEMU_MONITOR_IO_PROCESS: mon=0x7f0a603d33b0 buf={"id": "libvirt-41", >> "error": {"class": "GenericError", "desc": "this feature or command is >> not currently supported"}}^M >> len=120 > > Well, at least QEMU_MONITOR_ messages are showing, finally. The non-x86 > machines might be missing lot of commands that libvirt needs. Like > 'query-commands' which we need to know which commands we can run (bit of > a catch 22 right there). But these should not happen with x86, x86_64, > arm, arm64 (or aarch64), and few others. Those are being maintained > continuously.The messages only show when qemu is "sudo make install" from sources. In case it matters, all my existing VM's are x86_64.>> 2017-06-05 23:06:39.884+0000: 15559: debug : >> qemuMonitorJSONIOProcessLine:191 : Line [{"id": "libvirt-41", "error": >> {"class": "GenericError", "desc": "this feature or command is not >> currently supported"}}] >> 2017-06-05 23:06:39.884+0000: 15559: debug : virJSONValueFromString:1604 >> : string={"id": "libvirt-41", "error": {"class": "GenericError", "desc": >> "this feature or command is not currently supported"}} >> 2017-06-05 23:06:39.884+0000: 15559: debug : >> virJSONParserHandleStartMap:1478 : parser=0x7ffe4440afd0 >> >> >>> Have a nice day, >>> Martin >>> >> Thank you, you too! >> >> >> _______________________________________________ >> libvirt-users mailing list >> libvirt-users@redhat.com >> https://www.redhat.com/mailman/listinfo/libvirt-users
Martin Kletzander
2017-Jun-06 14:08 UTC
Re: [libvirt-users] libvirtd not accepting connections
On Tue, Jun 06, 2017 at 08:17:07AM -0400, Michael C. Cambria wrote:> > >On 06/06/2017 04:43 AM, Martin Kletzander wrote: >> On Mon, Jun 05, 2017 at 07:52:58PM -0400, Michael C Cambria wrote: >>> >>> >>> On 06/05/2017 10:46 AM, Martin Kletzander wrote: >>>> On Sun, Jun 04, 2017 at 06:42:39PM -0400, Michael C Cambria wrote: >>>>> I've upgraded from Fedora 20; probably missed a merge of rpmnew with >>>>> existing .conf; permission problem, some other mistake along the >>>>> way to >>>>> Fedora 25. >>>>> >>>> >>>> Yeah, probably some 'rpm -qV' (or whatever the command to verify all >>>> packages is) could help as well. >>> >>> "rpm -aV" didn't turn up anything obvious: >>> >>> S.5....T. c /etc/libvirt/libvirtd.conf was modified for logging: >>> # diff libvirtd.conf libvirtd.conf.rpmnew >>> 1,4d0 >>> < log_level = 1 >>> < log_filters="1:remote 1:event 1:json 1:rpc 1:qemu" >>> < log_outputs="1:file:/var/log/libvirt/libvirtd.log" >>> < # >>> # >>> >>>>> Is there a "how to" similar to [1] that lets one qemu to log that >>>>> it was >>>>> invoked and how far it got? >>>>> >>>>> I removed qemu (dnf remote qemu; sudo dnf remove qemu-common) >>>>> build qemu 2.2-maint (assuming this relates to 2:2.7.1-6.fc25) from >>>>> github sources >>>>> installed qemu from sources (into /usr/local/bin) >>>>> >>>>> Things are a bit better. Where something like "sudo virsh pool-list" >>>>> would just hang before, now my storage pools actually are listed. No >>>>> luck listing my VM's, but "virsh list" and "virsh list --all" do not >>>>> hang like before: >>>>> >>>>> # virsh list >>>> >>>> Are you sure you didn't miss the --all? >>>> >>> Yes I'm sure. I wish that was all it was <g> >>> >>>>> Id Name State >>>>> ---------------------------------------------------- >>>>> >>>>> # virsh pool-list >>>>> Name State Autostart >>>>> ------------------------------------------- >>>>> default active yes >>>>> Downloads active yes >>>>> guest_images_lvm active yes >>>>> >>>>> # >>>>> >>>>> VM xml is /etc/libvirt/qemu. The network, virbr0 is in >>>>> /etc/libvirt/qemu/networks, and that gets created just fine. All have >>>>> root:root owner:group: >>>>> >>>> >>>> The VMs are not visible because the XML cannot be parsed if the >>>> binaries >>>> are not on the system (the XML contains the whole path). Also, I think >>>> this works because libvirt doesn't look into /usr/local/bin, but I >>>> might >>>> be wrong. Check whether 'virsh capabilities' tells you something about >>>> any emulator. >>>> >>>> You can try installing from source, but putting it in /usr/bin, >>> >>> >>> I put qemu-system-x86_64 and qemu-x86_64 in /usr/bin as requested. No >>> luck. It seems /usr/local/bin/qemu-xxx is found (see CGroup: output) >>> >>> $ sudo systemctl status libvirtd.service >>> ● libvirtd.service - Virtualization daemon >>> Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; >>> vendor preset: enabled) >>> Active: active (running) since Mon 2017-06-05 18:21:20 EDT; 3s ago >>> Docs: man:libvirtd(8) >>> http://libvirt.org >>> Main PID: 7076 (libvirtd) >>> Tasks: 19 (limit: 4915) >>> Memory: 124.7M >>> CPU: 3.649s >>> CGroup: /system.slice/libvirtd.service >>> ├─7076 /usr/sbin/libvirtd >>> └─7208 /usr/local/bin/qemu-system-sh4eb -S -no-user-config >>> -nodefaults -nographic -M none -qmp >>> unix:/var/lib/libvirt/qemu/capabilities.monitor.sock,server,nowait >>> -pidfile /var/lib/libvirt/qemu/capabi >>> >> >> So this is now only with the qemu from source installed on the system? > >Correct. >> >>> $ sudo virsh list --all >>> Id Name State >>> ---------------------------------------------------- >>> >>> $ sudo virsh pool-list >>> Name State Autostart >>> ------------------------------------------- >>> default active yes >>> Downloads active yes >>> guest_images_lvm active yes >>> >>> $ >>> >>>> you can >>>> also remove that installation, put back the one from the package and >>>> try >>>> running: >>>> >>>> { for i in qmp_capabilities query-commands quit; do echo >>>> "{'execute':'$i'}"; done } | qemu-system-x86_64 -nographic -nodefaults >>>> -no-user-config -M none -qmp stdio >>>> >>>> And see whether the QEMU process quits, what it outputs and if it gets >>>> stuck, you can attach gdb and see what it's waiting for. Or maybe try >>>> running it with strace. >>> >>> This completed almost instantly. >>> >> >> And that is with the QEMU installed form the package, right? > >Correct > >> >>>> You can also do a thing I used to do a lot. You can rename >>>> /usr/bin/qemu-system-x86_64 (for example) and create a script with that >>>> filename that for example execs as qemu in strace with the output of >>>> strace put in some file, or similar. I can't think of anything else >>>> for >>>> now, sorry. >>> >>> I'll try this ASAP. First I'll look at all the QEMU_MONITOR_* log >>> entries that contain "error" that I *am* getting with qemu installed >>> from source (in /usr/local/bin/qemu-*) >>> >>> 2017-06-05 23:06:39.884+0000: 15559: info : >>> virEventPollDispatchHandles:506 : EVENT_POLL_DISPATCH_HANDLE: watch=11 >>> events=1 >>> 2017-06-05 23:06:39.884+0000: 15559: info : virObjectRef:296 : >>> OBJECT_REF: obj=0x7f0a603d33b0 >>> 2017-06-05 23:06:39.884+0000: 15559: info : qemuMonitorIOProcess:429 : >>> QEMU_MONITOR_IO_PROCESS: mon=0x7f0a603d33b0 buf={"id": "libvirt-41", >>> "error": {"class": "GenericError", "desc": "this feature or command is >>> not currently supported"}}^M >>> len=120 >> >> Well, at least QEMU_MONITOR_ messages are showing, finally. The non-x86 >> machines might be missing lot of commands that libvirt needs. Like >> 'query-commands' which we need to know which commands we can run (bit of >> a catch 22 right there). But these should not happen with x86, x86_64, >> arm, arm64 (or aarch64), and few others. Those are being maintained >> continuously. > >The messages only show when qemu is "sudo make install" from sources. >And what are they related to? Can you post the full log somewhere and send a link to it? I'll see if there's something usable.>In case it matters, all my existing VM's are x86_64. > >>> 2017-06-05 23:06:39.884+0000: 15559: debug : >>> qemuMonitorJSONIOProcessLine:191 : Line [{"id": "libvirt-41", "error": >>> {"class": "GenericError", "desc": "this feature or command is not >>> currently supported"}}] >>> 2017-06-05 23:06:39.884+0000: 15559: debug : virJSONValueFromString:1604 >>> : string={"id": "libvirt-41", "error": {"class": "GenericError", "desc": >>> "this feature or command is not currently supported"}} >>> 2017-06-05 23:06:39.884+0000: 15559: debug : >>> virJSONParserHandleStartMap:1478 : parser=0x7ffe4440afd0 >>> >>> >>>> Have a nice day, >>>> Martin >>>> >>> Thank you, you too! >>> >>> >>> _______________________________________________ >>> libvirt-users mailing list >>> libvirt-users@redhat.com >>> https://www.redhat.com/mailman/listinfo/libvirt-users >
Michael C. Cambria
2017-Jun-06 14:19 UTC
Re: [libvirt-users] libvirtd not accepting connections
On 06/06/2017 08:17 AM, Michael C. Cambria wrote:> > > On 06/06/2017 04:43 AM, Martin Kletzander wrote: >> On Mon, Jun 05, 2017 at 07:52:58PM -0400, Michael C Cambria wrote: >>> >>> >>> On 06/05/2017 10:46 AM, Martin Kletzander wrote: >>>> On Sun, Jun 04, 2017 at 06:42:39PM -0400, Michael C Cambria wrote: >>>>> I've upgraded from Fedora 20; probably missed a merge of rpmnew with >>>>> existing .conf; permission problem, some other mistake along the >>>>> way to >>>>> Fedora 25. >>>>> >>>> >>>> Yeah, probably some 'rpm -qV' (or whatever the command to verify all >>>> packages is) could help as well. >>> >>> "rpm -aV" didn't turn up anything obvious: >>> >>> S.5....T. c /etc/libvirt/libvirtd.conf was modified for logging: >>> # diff libvirtd.conf libvirtd.conf.rpmnew >>> 1,4d0 >>> < log_level = 1 >>> < log_filters="1:remote 1:event 1:json 1:rpc 1:qemu" >>> < log_outputs="1:file:/var/log/libvirt/libvirtd.log" >>> < # >>> # >>> >>>>> Is there a "how to" similar to [1] that lets one qemu to log that >>>>> it was >>>>> invoked and how far it got? >>>>> >>>>> I removed qemu (dnf remote qemu; sudo dnf remove qemu-common) >>>>> build qemu 2.2-maint (assuming this relates to 2:2.7.1-6.fc25) from >>>>> github sources >>>>> installed qemu from sources (into /usr/local/bin) >>>>> >>>>> Things are a bit better. Where something like "sudo virsh pool-list" >>>>> would just hang before, now my storage pools actually are listed. No >>>>> luck listing my VM's, but "virsh list" and "virsh list --all" do not >>>>> hang like before: >>>>> >>>>> # virsh list >>>> >>>> Are you sure you didn't miss the --all? >>>> >>> Yes I'm sure. I wish that was all it was <g> >>> >>>>> Id Name State >>>>> ---------------------------------------------------- >>>>> >>>>> # virsh pool-list >>>>> Name State Autostart >>>>> ------------------------------------------- >>>>> default active yes >>>>> Downloads active yes >>>>> guest_images_lvm active yes >>>>> >>>>> # >>>>> >>>>> VM xml is /etc/libvirt/qemu. The network, virbr0 is in >>>>> /etc/libvirt/qemu/networks, and that gets created just fine. All have >>>>> root:root owner:group: >>>>> >>>> >>>> The VMs are not visible because the XML cannot be parsed if the >>>> binaries >>>> are not on the system (the XML contains the whole path). Also, I think >>>> this works because libvirt doesn't look into /usr/local/bin, but I >>>> might >>>> be wrong. Check whether 'virsh capabilities' tells you something >>>> about >>>> any emulator. >>>> >>>> You can try installing from source, but putting it in /usr/bin, >>> >>> >>> I put qemu-system-x86_64 and qemu-x86_64 in /usr/bin as requested. No >>> luck. It seems /usr/local/bin/qemu-xxx is found (see CGroup: output) >>> >>> $ sudo systemctl status libvirtd.service >>> ● libvirtd.service - Virtualization daemon >>> Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; >>> vendor preset: enabled) >>> Active: active (running) since Mon 2017-06-05 18:21:20 EDT; 3s ago >>> Docs: man:libvirtd(8) >>> http://libvirt.org >>> Main PID: 7076 (libvirtd) >>> Tasks: 19 (limit: 4915) >>> Memory: 124.7M >>> CPU: 3.649s >>> CGroup: /system.slice/libvirtd.service >>> ├─7076 /usr/sbin/libvirtd >>> └─7208 /usr/local/bin/qemu-system-sh4eb -S -no-user-config >>> -nodefaults -nographic -M none -qmp >>> unix:/var/lib/libvirt/qemu/capabilities.monitor.sock,server,nowait >>> -pidfile /var/lib/libvirt/qemu/capabi >>> >> >> So this is now only with the qemu from source installed on the system? > > Correct.Using qemu installed from source, I decided to try to create a VM. It worked. I cut/pasted a script I used to create a centos72 VM, renamed the name and cut the disk size down: $ cat debug-centos.sh #/bin/bash sudo virt-install -n dbgcent72 \ --ram=4096 \ --vcpus 2 \ --disk path=/dev/vg_guest_images/dbgcent72,device=disk,size=5 \ --description "Centos 7.2 64Bit" \ --network bridge:brguest0,model=e1000 \ --cdrom /home/mcc/Downloads/CentOS-7-x86_64-DVD-1511.iso \ --vnc \ --noautoconsole \ --hvm \ --os-type=linux \ --os-variant centos7.0 \ --video=vmvga $ ./debug-centos.sh Starting install... Domain installation still in progress. You can reconnect to the console to complete the installation process. $ sudo virsh list --all Id Name State ---------------------------------------------------- 1 dbgcent72 running The xml is placed next to the xml for all the other VM's that don't seem to be found: # pwd /etc/libvirt/qemu # ls -al total 80 drwx------. 3 root root 4096 Jun 6 09:36 . drwx------. 5 root root 4096 Jun 6 08:38 .. -rw-------. 1 root root 3870 Jun 6 09:36 dbgcent72.xml -rw-------. 1 root root 3853 Jun 14 2016 dcos-bp.xml -rw-------. 1 root root 3551 Mar 21 2015 fbsd100.xml -rw-------. 1 root root 3273 Mar 23 2015 fbsd101.xml -rw-------. 1 root root 3867 Feb 21 2015 fedora20.xml drwx------. 3 root root 4096 May 10 18:08 networks -rw-------. 1 root root 3510 Oct 11 2015 u1404s.xml -rw-------. 1 root root 5017 Oct 11 2015 u1404.xml -rw-------. 1 root root 3507 Jun 5 19:33 wheezy.xml -rw-------. 1 root root 3489 Feb 21 2015 win7.xml # lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert [deleted] dbgcent72 vg_guest_images -wi-ao---- 5.00g dcos-bp vg_guest_images -wi-a----- 50.00g fbsd100 vg_guest_images -wi-a----- 20.00g fbsd101 vg_guest_images -wi-a----- 20.00g fedora20 vg_guest_images -wi-a----- 50.00g u1404s.qcow vg_guest_images -wi-a----- 40.00g wheezy vg_guest_images -wi-a----- 20.00g win7 vg_guest_images -wi-a----- 70.00g # ls -al /var/lib/libvirt/images total 12494552 drwx--x--x. 2 root root 4096 May 10 18:08 . drwxr-xr-x. 12 root root 4096 May 10 18:08 .. -rw-------. 1 root root 22552248320 May 29 2016 u1404.qcow2 #