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

[Cole Robinson]

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'


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

Thanks,
Cole