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
_______________________________________________
virt-tools-list mailing list
virt-tools-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/virt-tools-list
