New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Qubes Manager Doesn't Allow Editing of VM Settings or Management #3493

Open
SamuelHentschel opened this Issue Jan 24, 2018 · 6 comments

Comments

Projects
None yet
3 participants
@SamuelHentschel

SamuelHentschel commented Jan 24, 2018

Qubes OS version:

R3.2

Affected TemplateVMs:

Dom0


Steps to reproduce the behavior:

  1. Open Qubes VM Manager
  2. Choose a VM
  3. Click on the VM Settings buttons
    1. VM Settings
    2. Edit VM Firewall Rules
    3. Add/Remove Shortcuts for VM
    4. Etc

or

  1. Open Qubes VM Manager
  2. Choose a VM
  3. Click on the VM Management buttons
    1. Start VM
    2. Pause VM
    3. Etc.

Expected behavior:

Should be able to edit settings via the Qubes VM Manager GUI.

Actual behavior:

I get the following error:

libvirtError: internal error: client socket is closed
This is most likely a bug in the Qubes Manager

and under details I get:

line: if ret is None: raise libvirtError ('virNodeGetInfo() failed', conn=self)
func: getInfo
line no.: 3796
file: /usr/lib64/python2.7/site-packages/libvirt.py

line: (model, memory, cpus, mhz, nodes, socket, cores, threads) = vmm.libvirt_conn.getInfo()
func: init
line no.: 198
file: /usr/lib64/python2.7/site-packages/qubes/qubes.py

line: qubes_memory = QubesHost().memory_total/1024
func: init_advanced_tab
line no.: 478
file: /usr/lib64/python2.7/site-packages/qubesmanager/settings.py

line: self.init_advanced_tab()
func: init
line no.: 74
file: /usr/lib64/python2.7/site-packages/qubesmanager/settings.py

line: "basic")
func: action_settings_triggered
line no.: 1401
file: /usr/lib64/python2.7/site-packages/qubesmanager/main.py

General notes:


Related issues:

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Jan 24, 2018

Member

Looks like libvirt have crashed. To get Qubes Manager working back, restart it (right click on its icon, then "exit", and start new one from menu). But it would be useful to know what caused libvirt crash, see journalctl -u libvirtd -b and look for something resulting in service restart.

Member

marmarek commented Jan 24, 2018

Looks like libvirt have crashed. To get Qubes Manager working back, restart it (right click on its icon, then "exit", and start new one from menu). But it would be useful to know what caused libvirt crash, see journalctl -u libvirtd -b and look for something resulting in service restart.

@SamuelHentschel

This comment has been minimized.

Show comment
Hide comment
@SamuelHentschel

SamuelHentschel Jan 24, 2018

Would you like me to restart, get a clean log and send you everything that that command outputs?

Would you like me to restart, get a clean log and send you everything that that command outputs?

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Jan 24, 2018

Member

Better just lines from the time the problem happened, I guess it may be hard to reproduce the problem again. A wild guess - search for "assert" or "assert fail". Looking for service restart may also be helpful ("Starting Virtualization daemon").

Member

marmarek commented Jan 24, 2018

Better just lines from the time the problem happened, I guess it may be hard to reproduce the problem again. A wild guess - search for "assert" or "assert fail". Looking for service restart may also be helpful ("Starting Virtualization daemon").

@SamuelHentschel

This comment has been minimized.

Show comment
Hide comment
@SamuelHentschel

SamuelHentschel Jan 24, 2018

Jan 23 11:39:39 dom0 systemd[1]: Starting Virtualization daemon...
Jan 23 11:39:39 dom0 systemd[1]: Started Virtualization daemon.
Jan 23 11:39:39 dom0 libvirtd[1363]: libvirt version: 1.2.20, package: 6.fc23 (Unknown, 2016-06-04-18:32:35, releas
Jan 23 11:39:39 dom0 libvirtd[1363]: no connection driver available for qemu:///system
Jan 23 11:39:41 dom0 root[1889]: /etc/xen/scripts/block-snapshot: add XENBUS_PATH=backend/vbd/1/51712
Jan 23 11:39:41 dom0 root[1910]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/1/51760
Jan 23 11:39:51 dom0 root[2355]: /etc/xen/scripts/block-snapshot: add XENBUS_PATH=backend/vbd/2/51712
Jan 23 11:39:51 dom0 root[2412]: /etc/xen/scripts/block-snapshot: Writing backend/vbd/2/51712/node /dev/mapper/snap
Jan 23 11:39:51 dom0 root[2431]: /etc/xen/scripts/block-snapshot: Writing backend/vbd/2/51712/physical-device fd:3
Jan 23 11:40:01 dom0 libvirtd[1363]: internal error: Unable to reset PCI device 0000:00:14.0: no FLR, PM reset or b
Jan 23 11:40:02 dom0 root[3193]: /etc/xen/scripts/block-snapshot: add XENBUS_PATH=backend/vbd/4/51712
Jan 23 11:40:02 dom0 root[3373]: /etc/xen/scripts/block-snapshot: Writing backend/vbd/4/51712/physical-device fd:5
Jan 23 11:40:03 dom0 root[3421]: /etc/xen/scripts/block: Writing backend/vbd/4/51744/node /dev/loop13 to xenstore.
Jan 23 11:40:03 dom0 root[3437]: /etc/xen/scripts/block: Writing backend/vbd/4/51744/physical-device 7:d to xenstor
Jan 23 11:41:15 dom0 root[4268]: /etc/xen/scripts/block: Writing backend/vbd/5/51728/hotplug-status connected to xe
Jan 23 11:41:16 dom0 root[4453]: /etc/xen/scripts/block: Writing backend/vbd/5/51744/physical-device 7:12 to xensto
Jan 23 11:41:29 dom0 root[4541]: /etc/xen/scripts/block-snapshot: remove XENBUS_PATH=backend/vbd/5/51712
Jan 23 11:41:29 dom0 root[4569]: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/5/51760
Jan 23 11:43:39 dom0 libvirtd[1363]: End of file while reading data: Input/output error
Jan 23 11:43:45 dom0 root[5351]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/6/51712
Jan 23 11:43:45 dom0 root[5495]: /etc/xen/scripts/block: Writing backend/vbd/6/51728/hotplug-status connected to xe
Jan 23 11:46:43 dom0 root[6382]: /etc/xen/scripts/block-snapshot: add XENBUS_PATH=backend/vbd/7/51712
Jan 23 11:46:43 dom0 root[6411]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/7/51744
Jan 23 11:46:50 dom0 root[7126]: /etc/xen/scripts/block: Writing backend/vbd/8/51728/physical-device 7:18 to xensto
Jan 23 11:47:35 dom0 root[7472]: /etc/xen/scripts/block-snapshot: add XENBUS_PATH=backend/vbd/9/51712
Jan 23 11:47:35 dom0 root[7487]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/9/51728
Jan 23 11:47:35 dom0 root[7504]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/9/51744
Jan 23 11:47:35 dom0 root[7510]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/9/51760

SamuelHentschel commented Jan 24, 2018

Jan 23 11:39:39 dom0 systemd[1]: Starting Virtualization daemon...
Jan 23 11:39:39 dom0 systemd[1]: Started Virtualization daemon.
Jan 23 11:39:39 dom0 libvirtd[1363]: libvirt version: 1.2.20, package: 6.fc23 (Unknown, 2016-06-04-18:32:35, releas
Jan 23 11:39:39 dom0 libvirtd[1363]: no connection driver available for qemu:///system
Jan 23 11:39:41 dom0 root[1889]: /etc/xen/scripts/block-snapshot: add XENBUS_PATH=backend/vbd/1/51712
Jan 23 11:39:41 dom0 root[1910]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/1/51760
Jan 23 11:39:51 dom0 root[2355]: /etc/xen/scripts/block-snapshot: add XENBUS_PATH=backend/vbd/2/51712
Jan 23 11:39:51 dom0 root[2412]: /etc/xen/scripts/block-snapshot: Writing backend/vbd/2/51712/node /dev/mapper/snap
Jan 23 11:39:51 dom0 root[2431]: /etc/xen/scripts/block-snapshot: Writing backend/vbd/2/51712/physical-device fd:3
Jan 23 11:40:01 dom0 libvirtd[1363]: internal error: Unable to reset PCI device 0000:00:14.0: no FLR, PM reset or b
Jan 23 11:40:02 dom0 root[3193]: /etc/xen/scripts/block-snapshot: add XENBUS_PATH=backend/vbd/4/51712
Jan 23 11:40:02 dom0 root[3373]: /etc/xen/scripts/block-snapshot: Writing backend/vbd/4/51712/physical-device fd:5
Jan 23 11:40:03 dom0 root[3421]: /etc/xen/scripts/block: Writing backend/vbd/4/51744/node /dev/loop13 to xenstore.
Jan 23 11:40:03 dom0 root[3437]: /etc/xen/scripts/block: Writing backend/vbd/4/51744/physical-device 7:d to xenstor
Jan 23 11:41:15 dom0 root[4268]: /etc/xen/scripts/block: Writing backend/vbd/5/51728/hotplug-status connected to xe
Jan 23 11:41:16 dom0 root[4453]: /etc/xen/scripts/block: Writing backend/vbd/5/51744/physical-device 7:12 to xensto
Jan 23 11:41:29 dom0 root[4541]: /etc/xen/scripts/block-snapshot: remove XENBUS_PATH=backend/vbd/5/51712
Jan 23 11:41:29 dom0 root[4569]: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/5/51760
Jan 23 11:43:39 dom0 libvirtd[1363]: End of file while reading data: Input/output error
Jan 23 11:43:45 dom0 root[5351]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/6/51712
Jan 23 11:43:45 dom0 root[5495]: /etc/xen/scripts/block: Writing backend/vbd/6/51728/hotplug-status connected to xe
Jan 23 11:46:43 dom0 root[6382]: /etc/xen/scripts/block-snapshot: add XENBUS_PATH=backend/vbd/7/51712
Jan 23 11:46:43 dom0 root[6411]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/7/51744
Jan 23 11:46:50 dom0 root[7126]: /etc/xen/scripts/block: Writing backend/vbd/8/51728/physical-device 7:18 to xensto
Jan 23 11:47:35 dom0 root[7472]: /etc/xen/scripts/block-snapshot: add XENBUS_PATH=backend/vbd/9/51712
Jan 23 11:47:35 dom0 root[7487]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/9/51728
Jan 23 11:47:35 dom0 root[7504]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/9/51744
Jan 23 11:47:35 dom0 root[7510]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/9/51760

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Jan 25, 2018

Member

Does the time matches when the problem happened?

Member

marmarek commented Jan 25, 2018

Does the time matches when the problem happened?

@SamuelHentschel

This comment has been minimized.

Show comment
Hide comment
@SamuelHentschel

SamuelHentschel Jan 30, 2018

I believe so? I'd have to test it again to make sure they are correlated. Like I said in #3491 I believe this may be related to an ACPI error I am having when I boot up. I'll try and get a copy of that ACPI error and see if it is related. If not, then I'll make another issue.

I believe so? I'd have to test it again to make sure they are correlated. Like I said in #3491 I believe this may be related to an ACPI error I am having when I boot up. I'll try and get a copy of that ACPI error and see if it is related. If not, then I'll make another issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment