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

[Povilas Kanapickas]

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.

> 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.

Regards,
Povilas