[virt-tools-list] [virt-manager] Any interest in the <clock> element?

[Povilas Kanapickas]

On 11/01/2019 20:56, Cole Robinson wrote:
> On 01/11/2019 11:47 AM, Povilas Kanapickas wrote:
>> On 10/01/2019 19:00, Cole Robinson wrote:
>>> On 01/10/2019 04:43 AM, Pavel Hrdina wrote:
>>>> On Wed, Jan 09, 2019 at 11:31:51PM +0200, Povilas Kanapickas wrote:
>>>>> Hey,
>>>>>
>>>>> Does it make sense to wrap the data in the <clock> element [1] within
>>>>> the virt-manager GUI? I would be interested in implementing support
>>>>> for
>>>>> that.
>>>>
>>>> Hi,
>>>>
>>>> I'm not so sure about this feature in GUI.  I don't know the current
>>>> state in virt-manager/virt-install but it sounds that we should pick
>>>> the best default based on the selected/detected os-variant during
>>>> installation.  But fine-tuning these attributes sounds more like
>>>> advanced feature which we usually try not to introduce in GUI for now.
>>>>
>>>> So if virt-manager/virt-install is not selecting the best configuration
>>>> patches to fix that would be definitely welcomed.  From the
>>>> documentation it looks like the best configuration depends on the OS
>>>> installed inside the guest, we try to put all this information into
>>>> osinfo-db project which virt-manager/virt-install already uses.
>>>>
>>>
>>> I agree with all this.
>>
>> In fact, I agree with you too :-) Editing <timer> elements should be
>> rare enough so that there's no need for GUI.
>>
>> My use case is the offset="variable" adjustment="123" to bring the VM
>> backward or forward in time. I think a calendar GUI element would be
>> really useful here, editing XML is very inconvenient as one needs to do
>> a conversion between the date one wants to bring VM to and the offset in
>> seconds.
>>
>> What do you think if there was a drop-down "Synchronize with" where one
>> could specify the following?
>>
>> "UTC" - corresponds to offset="utc"
>>
>> "Localtime" - corresponds to offset="localtime"
>>
>> "Timezone" - corresponds to offset="timezone" and there also would be a
>> drop-down for timezone="xyz" attribute.
>>
>> "UTC and offset" - corresponds to offset="variable". There's also an
>> calendar element to specify current date of the VM.
>>
>> That's much easier compared to editing XML manually.
>>
> 
> Yes that's certainly a use case where editing XML manually sucks and a
> clicky calendar would be nice. But again this is very niche to add UI
> support for IMO. I bet you can script this nicely with virt-xml and a
> bit of python. Stick the script in your path and you can probably just
> alt+f2 'adjust-vm-day $NUMDAYS $VMNAME'
> 

Indeed it's possible to easily script this, in fact that's the approach
which I'm currently using.

With regards to whether the feature is niche or not, do you have some
kind of "measurement" process of evaluating this? I guess that some
features could be useful to a large number of users, but they currently
see virt-manager not supporting it and either use other products or just
script it and don't spend time complaining on the mailing lists. As I
see now, it could be that the only way to signify that a feature is
useful is to be a large commercial client of RedHat and use the
available support channels. Could maybe some website where users could
vote on features or something else with low barrier of entry work?

Of course, I'm biased as this is not the first my proposal being
rejected, but please don't be offended by my questions, I'm genuinely
interested in projects under libvirt umbrella succeeding :-)

> 
>>> I realize though that users that just want to live in a single app want
>>> a UI way to edit any XML property they might need. So I'm planning in
>>> the medium term to explore a raw XML editing mode in virt-manager. This
>>> will take the pressure off of us to implement UI for these type of XML
>>> properties that aren't commonly adjusted, allow us to reduce the UI
>>> surface further, which will make the app easier to maintain over the
>>> long term.
>>>
>>> For domains, I'm thinking either a tab in the Details->Overview page,
>>> which will show the full domain XML, or its own entry in the hardware
>>> list, like 'Domain XML'. Individual device info pages could have a tab
>>> at the top labeled 'Device XML' if the user just wants to edit a single
>>> device. The text viewer should probably be gtksourceview which I believe
>>> has XML syntax highlighting support, but I've never used the API so I
>>> can't speak from experience.
>>>
>>> If that works out then there's opportunities to extend this paradigm to
>>> the virtual networks and storage pools pages, and to the wizards
>>> addhardware, createnet, createpool, createvol, maybe cloning too.
>>>
>>> So Povilas if you are interested in a project, that's an option. A first
>>> pass doesn't need to be perfect, I assume there's going to be some
>>> hidden pitfalls, but a starting point will help get the ball rolling
>>
>> I think this idea is really cool and would also be useful to me
>> personally as I'm already switching to a text editor back and forth very
>> frequently. I guess I can't promise that I will start working on this
>> right away, but it's a thing I would have interest to implement when I
>> have time. Hooking this up to the `virt-xml-validate` tool would make
>> the editor even more convenient.
> 
> Indeed though it would probably be processing the .rng files directly
> rather than calling out to virt-xml-validate. I know libvirt has some
> API support for validating XML but it might only be at define/create
> time. Otherwise .rng files are in /usr/share/libvirt/schemas and can be
> used for validation directly

That's great to know, thanks!

Regards,
Povilas