Add "view, edit, and add Video devices" to detailspage

[Shotaro-Kawaguchi]

Added a feature to display video devices in virtual machine information.
With this commit, it will be possible to add, edit, and delete video devices.
This feature was implemented by a use case that sets a VNC password.

Screenshot viewing video device.

Click the "Add video device" button to display the following screen.

Click the "Edit" button to display the following screen.

Click the "..." button to display the following screen.

Click the "Remove" button to display the following screen.

[jelly]

Thanks for the PR!

Without diving to deep into the PR and testing it out. We have discussed improving the VNC/Spice UI in the past here making it configurable. I need to look if I can find more recent design proposals.

Is adding more devices a hard requirement or is just changing the default port/host/password good enough?

[martinpitt]

@Shotaro-Kawaguchi : Thanks! Some initial notes:

• spice is deprecated in RHEL 8 and unsupported in RHEL 9 and 10. A few months ago we went through some great efforts to move users away from SPICE. So adding an option to add spice graphics is contrary to that.

• Does it make sense to add more than one VNC device? I don't know exactly, but I remember something like "you can only add one of each type".

• So perhaps it is enough to start with the "Edit VNC" functionality to set a password?

• This needs integration tests for all code paths, which in its current form is a big combinatorial explosion (add/remove multiple types/devices/password/varying OS support). Unfortunately it will take our team very long to help with that as we don't have a current machines maintainer. So it would be good if you could work on them yourself? (Happy to guide, of course)

• needsShutdownVideo() and its conditional code should be removed, as it's a constant False. It removes a code path.

I suggest to start with a single feature addition (like set/change VNC password), cover it with proper tests, and then add more things as follow-up PRs if there's any use case.

[garrett]

Thanks for this PR! We have had a design for this for a few years already, as @jelly pointed out.

Hopefully this PR is enough to push the feature forward. If that's the case, perhaps I can find some time to revisit the design and adjust it. It's been in a "holding pattern", waiting for someone to start working on it, so I can allocate time to it again.

Having fewer options (in other words: removing SPICE) should help simplify the UI further too.

Are there any use cases for having more than one VNC display per VM? All I can think about are:

1. Graphics vs. text mode... but you'd likely want to use SSH for text instead.
2. Multi-user setups, where people are using VNC or RDP to log into a host remotely. (But I'm not sure Cockpit is the best way to maintain a setup like that?) Even still: Having multiple VNC displays would probably be best by selecting the # and having ports allocated, right?
3. Having one app per VNC port might make some kind of sense, maybe? But I think this is a very specific use case and not really realistic?

We shouldn't add something because you can do it, but because it's actually useful to do. I don't think any of the above are really typical uses of running VMs on a server using Cockpit. (Please prove me wrong though, and/or provide other realistic cases.)

We had an issue suggesting adding VNC like in this PR before, but it doesn't make sense, as we have a dedicated place for graphics and remote graphics is quite different from other devices for several reasons. (It's integrated in-page, it really probably should be just 1 connection, it has graphical and text modes, it's not really a standard virtualize device provided to the VM like disks and network cards, and we already have a place for graphics at the top so we shouldn't have two different places for it.)

Also, I need to point out again that this feature is mostly useless as-is standalone, as it requires having access to the ports, which means either poking holes in the firewall or turning off a firewall. To really make this useful, we'd want to add in firewall integration. This doesn't mean we shouldn't make it better (we definitely should), but that we shouldn't stop just here. In other words, we need to make sure this works on a remote server (without jumping through hoops), not just from localhost.

Again, thank you for "getting the ball rolling again" with this PR! It's a good first step to getting remote graphics support improved overall!

[Shotaro-Kawaguchi]

@jelly Thank you for your response.

Is adding more devices a hard requirement or is just changing the default port/host/password good enough?
The hard requirement for this use case is to be able to change the VNC password.

[Shotaro-Kawaguchi]

@martinpitt Thank you for your response.

spice is deprecated in RHEL 8 and unsupported in RHEL 9 and 10. A few months ago we went through some great efforts to move users away from SPICE. So adding an option to add spice graphics is contrary to that.

I was not aware that the SPICE type is deprecated. Thank you for pointing it out.
I will remove the option to select the SPICE device type.

Does it make sense to add more than one VNC device? I don't know exactly, but I remember something like "you can only add one of each type".

I was not aware of the number of devices that can be added. Thank you for pointing it out.
I will fix it so that only one VNC device can be added.

This needs integration tests for all code paths, which in its current form is a big combinatorial explosion (add/remove multiple types/devices/password/varying OS support). Unfortunately it will take our team very long to help with that as we don't have a current machines maintainer. So it would be good if you could work on them yourself? (Happy to guide, of course)

I will try to create test code.

needsShutdownVideo() and its conditional code should be removed, as it's a constant False. It removes a code path.
Got it. I will remove the needsShutdownVideo() function.

In this pull request, I will make it possible to view, delete, and change the password of VNC devices.

[Shotaro-Kawaguchi]

We had an issue suggesting adding VNC like in this PR before, but it doesn't make sense, as we have a dedicated place for graphics and remote graphics is quite different from other devices for several reasons. (It's integrated in-page, it really probably should be just 1 connection, it has graphical and text modes, it's not really a standard virtualize device provided to the VM like disks and network cards, and we already have a place for graphics at the top so we shouldn't have two different places for it.)

Would it be good to move the button as shown in the attached image?

[garrett]

@Shotaro-Kawaguchi: Can you reply to my comment above please? Have you looked at the mockups? (The current mockups are @ #553 (comment).)

I'll have to adapt the mockups for the SPICE removal (and I've started doing that).

But I won't merge this PR if it's about adding VNC in a different place. We need to have the VNC console be an integrated experience, not scattered across the page.

Since you're interested, I did dust off the old designs and started to update them and would be happy to work with you to get the features integrated... as long as the design of it is considered.

Thanks!

(I think we always have VNC in all VMs Cockpit creates. In VMs where it's not enabled, we could have edit implicitly create it. In the edit dialog, we could also have a remove action. I could try to illustrate this in a mockup tomorrow, as it's getting late here today.)

[Shotaro-Kawaguchi]

@garrett

Can you reply to my comment above please? Have you looked at the mockups? (The current mockups are @ #553 (comment).)

I apologize for the delayed reply.
I have looked at the current mockups. The image I posted above was not good.
In the following comments, similar things are said, but in the current mockups, how will the VNC display be added if it does not exist in the current mockups?
#553 (comment)

Are there any use cases for having more than one VNC display per VM?

I was not aware that assigning multiple VNC displays to a VM would prevent the VM from starting due to the following error. So, I think one VNC display is sufficient.

error: Failed to start domain 'vm1'
error: unsupported configuration: only 1 graphics device of each type (sdl, vnc, spice, headless, dbus) is supported

[garrett]

In the following comments, similar things are said, but in the current mockups, how will the VNC display be added if it does not exist in the current mockups?

I've spent a little bit of time to start to update the mockups a bit and even designed an "empty state" pattern that would make it easy to add VNC if it hadn't been added to a machine already.

By default, machines with VNC and serial text consoles would look like this:

Here's what clicking on "Text" would look like:

If a machine does not have VNC support, then it should probably default to text, and if the VNC tab is active, then we could display a message saying that the support has not been enabled and that it can be added. That would look like this, which would have a button that would add VNC support with defaults set up in the same way VNC support is added to VMs created by Cockpit:

[Shotaro-Kawaguchi]

Thank you for sending the mockups.
I think these mockups are very good.

[jelly]

In the following comments, similar things are said, but in the current mockups, how will the VNC display be added if it does not exist in the current mockups?

I've spent a little bit of time to start to update the mockups a bit and even designed an "empty state" pattern that would make it easy to add VNC if it hadn't been added to a machine already.

By default, machines with VNC and serial text consoles would look like this:

Here's what clicking on "Text" would look like:

If a machine does not have VNC support, then it should probably default to text, and if the VNC tab is active, then we could display a message saying that the support has not been enabled and that it can be added. That would look like this, which would have a button that would add VNC support with defaults set up in the same way VNC support is added to VMs created by Cockpit:

We still support SPICE on Fedora as only RHEL dropped it but Fedora and other distros still have it around. So it should be possible add or remove it.

[Shotaro-Kawaguchi]

I plan to proceed with the implementation according to the mockup created by Garrett.
First, how about implementing the VNC device and considering SPICE later if necessary?
@garrett Do you already have the source code that can operate like the mockup? If so, could you share it with us?

[garrett]

@Shotaro-Kawaguchi There's no "source code" for the mockup, as it's a mockup (and not a prototype). I do have a Penpot file of the current state:

• VM console options.penpot.zip

(You'd have to extract the zip file, then import the penpot file in Penpot.)

I've already exported the interesting parts as PNGs and attached them above.

[Shotaro-Kawaguchi]

@garrett Thank you for sharing the mockup.
I will proceed with the implementation based on this.

[Shotaro-Kawaguchi]

There are some differences from the mockup, but I have implemented the functional parts of addition and editing.

[Shotaro-Kawaguchi]

@garrett @martinpitt
I have revised the implementation based on the mockup, so please review it.