Re: [virt-manager] Any interest in the <clock> element?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

_______________________________________________
virt-tools-list mailing list
virt-tools-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/virt-tools-list




[Index of Archives]     [Linux Virtualization]     [KVM Development]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]     [Video 4 Linux]

  Powered by Linux