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

[Cole Robinson]

On 01/12/2019 04:47 PM, Povilas Kanapickas wrote:
> 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 :-)
> 

No measurement besides my personal experience. So time spent working on 
the virt-manager and libvirt, communicating with users through bugs and 
feature requests and other support channels for over a decade basically. 
This includes dealing with hundreds of libvirt and qemu distro bugs too 
so it's not just limited to virt usage strictly through virt-manager but 
across the whole libvirt stack. Of course, that experience is biased in 
some obvious ways (I work for Red Hat and much of my interactions have 
come from distro users or customers through that lens) and likely some 
non-obvious ways too that I don't know about :)

I've seen reports of people using offset=variable on rare occasion for 
bug reproducing and similar things, but never heard about it as a 
recurring task. I think rhev/ovirt used to set it automatically based on 
some criteria but I'm not sure what that was about and that was 
presumably across a wide pool of VMs.

Also, if a redhat customer filed a request for the exact same UI, I 
would tell them the same thing: it's fairly niche/specialized, there are 
workarounds, and I don't think it's worth the long term maintenance 
effort or additional UI surface to justify adding the feature. Maybe I'd 
lose that argument for business reasons, maybe there use case would be 
sufficiently compelling or they have a large pool of users who need it, 
but for starters I would still argue against it

I'm sorry about the frustration here... I need to write up a document 
explicitly describing what I see as acceptable UI extensions, including 
lists of examples of previously rejected UI bits. I've been putting that 
off until I explored the raw XML editing mode...

- Cole