Avoid cryptic error messages in Qubes Manager

[andrewdavidwong]

Attempting to change the netvm of an AppVM resulted in this:

Error: 12

Is there a place to view the meanings of such error codes? Even if there is, it seems like there's no reason not to include a more verbose message in the error popup window. We're not really character-limited there. (Well, at least not that character-limited.)

[marmarek]

On Thu, Oct 08, 2015 at 03:09:51PM -0700, Axon wrote:

Attempting to change the netvm of an AppVM resulted in this:

Error: 12

Is there a place to view the meanings of such error codes? Even if there is, it seems like there's no reason not to include a more verbose message in the error popup window. We're not really character-limited there. (Well, at least not that character-limited.)

It isn't error code. It's probably error message, from KeyError
exception. Should be caught earlier and presented with proper message.
Or shouldn't happen at all ;)

Did you tried to change netvm to some just created or just deleted
NetVM? Can you provide steps to reproduce it?

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

On Thu, Oct 08, 2015 at 03:09:51PM -0700, Axon wrote:

Attempting to change the netvm of an AppVM resulted in this:

Error: 12

Is there a place to view the meanings of such error codes? Even if there is, it seems like there's no reason not to include a more verbose message in the error popup window. We're not really character-limited there. (Well, at least not that character-limited.)

It isn't error code. It's probably error message, from KeyError
exception. Should be caught earlier and presented with proper message.
Or shouldn't happen at all ;)

Did you tried to change netvm to some just created or just deleted
NetVM? Can you provide steps to reproduce it?

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[andrewdavidwong]

Did you tried to change netvm to some just created or just deleted NetVM?

No, the netvms have all been around for a while.

Can you provide steps to reproduce it?

Actually, it seems that most/all of my VMs are like this now. I just tried changing the netvm on a different VM, and here's what happened.

First popup:

[Dom0] Error while changing settings for <vmname>!


   <! icon>    ERROR: Basic tab:
               internal error: libxenlight failed to detach network device

Then I tried again. Second popup:

[Dom0] Error while changing settings for <vmname>!

   <! icon>    ERROR: Basic tab:
               12

The two-digit number is different for different VMs.

[andrewdavidwong]

Did you tried to change netvm to some just created or just deleted NetVM?

No, the netvms have all been around for a while.

Can you provide steps to reproduce it?

Actually, it seems that most/all of my VMs are like this now. I just tried changing the netvm on a different VM, and here's what happened.

First popup:

[Dom0] Error while changing settings for <vmname>!


   <! icon>    ERROR: Basic tab:
               internal error: libxenlight failed to detach network device

Then I tried again. Second popup:

[Dom0] Error while changing settings for <vmname>!

   <! icon>    ERROR: Basic tab:
               12

The two-digit number is different for different VMs.

[andrewdavidwong]

OK, so I tried shutting down the VM, then changing the netvm, and it worked. And now it works on the other VMs where it wasn't working before. Strange.

[andrewdavidwong]

OK, so I tried shutting down the VM, then changing the netvm, and it worked. And now it works on the other VMs where it wasn't working before. Strange.

[marmarek]

Ah, *running VM. It's probably #975 - in short - VM kernel crash when the
network got disconnected.

[marmarek]

Ah, *running VM. It's probably #975 - in short - VM kernel crash when the
network got disconnected.

[andrewdavidwong]

But one of the VMs which was exhibiting the problem was not running...

I tried with two VMs. One was shut down; one was running. The first (shut down) one exhibited the problem. Then the second (running) one did also. Then I shut down the second one, changed the netvm, and it worked. Then I tried again to change the first (still shut down the whole time) VM's netvm, and it then worked too.

But I think the first VM first exhibited the problem when I tried changing its netvm while it was running (and the problem just persisted even after it was shut down, even across host reboot.)

[andrewdavidwong]

But one of the VMs which was exhibiting the problem was not running...

I tried with two VMs. One was shut down; one was running. The first (shut down) one exhibited the problem. Then the second (running) one did also. Then I shut down the second one, changed the netvm, and it worked. Then I tried again to change the first (still shut down the whole time) VM's netvm, and it then worked too.

But I think the first VM first exhibited the problem when I tried changing its netvm while it was running (and the problem just persisted even after it was shut down, even across host reboot.)

[marmarek]

On Thu, Oct 08, 2015 at 04:20:51PM -0700, Axon wrote:

But one of the VMs which was exhibiting the problem was not running...

I tried with two VMs. One was shut down; one was running. The first (shut down) one exhibited the problem. Then the second (running) one did also. Then I shut down the second one, changed the netvm, and it worked. Then I tried again to change the first (still shut down the whole time) VM's netvm, and it then worked too.

But I think the first VM first exhibited the problem when I tried changing its netvm while it was running (and the problem just persisted even after it was shut down, even across host reboot.)

---

Reply to this email directly or view it on GitHub:
#1300 (comment)

Yes, strange. But probably since failed netvm detach attempt, some
internal state (libvirt vs libxl vs qubes.xml) got desynchronized.

Maybe we should block changing netvm in runtime until #975 got fixed?

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

On Thu, Oct 08, 2015 at 04:20:51PM -0700, Axon wrote:

But one of the VMs which was exhibiting the problem was not running...

I tried with two VMs. One was shut down; one was running. The first (shut down) one exhibited the problem. Then the second (running) one did also. Then I shut down the second one, changed the netvm, and it worked. Then I tried again to change the first (still shut down the whole time) VM's netvm, and it then worked too.

But I think the first VM first exhibited the problem when I tried changing its netvm while it was running (and the problem just persisted even after it was shut down, even across host reboot.)

---

Reply to this email directly or view it on GitHub:
#1300 (comment)

Yes, strange. But probably since failed netvm detach attempt, some
internal state (libvirt vs libxl vs qubes.xml) got desynchronized.

Maybe we should block changing netvm in runtime until #975 got fixed?

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[andrewdavidwong]

Maybe we should block changing netvm in runtime until #975 got fixed?

One use-case that might break is when the DVM template's netvm is intentionally set to 'none', then the user selectively and manually changes some DispVMs' netvm (after starting them, of course). But this functionality is arguably not as essential now that we can specify dispvm_netvm.

[andrewdavidwong]

Maybe we should block changing netvm in runtime until #975 got fixed?

One use-case that might break is when the DVM template's netvm is intentionally set to 'none', then the user selectively and manually changes some DispVMs' netvm (after starting them, of course). But this functionality is arguably not as essential now that we can specify dispvm_netvm.

[marmarek]

Hmm, since the kernel bug affects only detaching network interface, it
may still be allowed to attach some netvm, but not detach.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

Hmm, since the kernel bug affects only detaching network interface, it
may still be allowed to attach some netvm, but not detach.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[andrewdavidwong]

Ah, good point then.

[andrewdavidwong]

Ah, good point then.

[DeltaHeavy]

In this same vein (that of cryptic errors), when a PCI passthrough VM fails to de-assign a USB block device from a VM, you get a blocking popup with no content in the VM Manager, with the title "Houston, we have a problem.."

[DeltaHeavy]

In this same vein (that of cryptic errors), when a PCI passthrough VM fails to de-assign a USB block device from a VM, you get a blocking popup with no content in the VM Manager, with the title "Houston, we have a problem.."