Notfications of losses when changing vm template

[phyzical]

Hey there

 

loving unraid so far,

 

While ive been making changes to vms that are not in the list of supported options, i.e switching between gui and xml, it can be a bit annoying to have to re add said custom options, so i had a thought what if we could notify the user on save on an xml template to display the options being lost (at the very least) and maybe give the choice to keep such options that will be lost? or maybe let them choose what to keep and what to ditch?

 

If i wanted to try to make such a feature where would i go about starting (repo/development infra wise)? I dont feel it would be too difficult just an extra modal/form step and submission server side with a  diff of before and after template to determine what to show. or is this part of unraid not opensource?

 

if not ill leave it as a feature request

 

Thanks!

[itimpi]

I think this may be harder to implement than it first seems?

 

I do think, however that at a minimum a warning on switching from xml to form mode that changes made in cml mode may well be lost should be added?

[bonienl]

The objective is to keep customizations as much as possible. Ideally all, but sometimes this is not possible due to various reasons.

You can open a report with details which settings (you XML file) get lost and we can look into how to preserve them, if possible.

 

[itimpi]

5 minutes ago, bonienl said:

The objective is to keep customizations as much as possible. Ideally all, but sometimes this is not possible due to various reasons.

You can open a report with details which settings (you XML file) get lost and we can look into how to preserve them, if possible.

 

I had wondered if even in form mode you could have a text box that included all top level xml nodes that are not part of the standard templates.    A feature like that might mean one rarely needed to go into xml mode (as well as showing what custom xml nodes have been inserted).

[phyzical]

i understand there would be times were things should get lost to avoid issues in the template configuration or maybe when one changes to a new unraid version and options are redundant.

i will make a report will the things im seeing get lost to a save as a solution going forward.

 

itimpi's idea does sound like a nice middle ground. and should help with custom qemu settings (referencing spaceinvaders new container) i.e 

Quote

<qemu:commandline>
    <qemu:arg value='-usb'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='usb-kbd,bus=usb-bus.0'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='isa-applesmc,osk=REDACTED'/>
    <qemu:arg value='-smbios'/>
    <qemu:arg value='type=2'/>
    <qemu:arg value='-cpu'/>
    <qemu:arg value='Penryn,kvm=on,vendor=GenuineIntel,+invtsc,vmware-cpuid-freq=on,+pcid,+ssse3,+sse4.2,+popcnt,+avx,+aes,+xsave,+xsaveopt,check'/>
  </qemu:commandline>

but would not help with things like metadata, os and network override

Quote

<metadata>
    <vmtemplate xmlns="unraid" name="MacOS" icon="/mnt/user/domains/MacinaboxCatalina/icon/catalina.png" os="Catalina"/>
  </metadata>

  <os>
    <type arch='x86_64' machine='pc-q35-3.1'>hvm</type>
    <loader readonly='yes' type='pflash'>/mnt/user/domains/MacinaboxCatalina/ovmf/OVMF_CODE.fd</loader>
    <nvram>/mnt/user/domains/MacinaboxCatalina/ovmf/OVMF_VARS.fd</nvram>
  </os>
e1000-82545em

 

 

before i give up on the suggestion at the very least would diff on save not be possible to return the things that have been/will be dropped?

or a more complicated approach version control of xmls allowing for a diff in the same sense as say pull requests, taking this as a thought i guess choosing what to keep as i originally suggested isnt as easy as i thought as you end up with "conflicts" haha.

 

at the very least keeping a copy of say the last X xmls for a vm in a tab maybe? (im sure people do this manually anyway in cause of breaking things on change/testing anyway)

 

thanks for listening!