Description of problem: When I change domain HW configuration, virt-manager removes all custom (uknown to him) options from the config file Version-Release number of selected component (if applicable): virt-manager-0.5.3-8.el5 also tested on virt-manager-0.5.4-4.fc9.i386 How reproducible: always Steps to Reproduce: 1. echo 'custom_option = "some value"' >> /etc/xen/domainXYZ 2. change the domain via virt-manager (ie disconnect/connect cdrom image) 3. grep custom_option /etc/xen/domainXYZ Actual results: custom options are gone Expected results: domain config is changed and all custom option are preserved, unchanged and in the same order as before the change Additional info:
This is a known limitation of the way we manage inactive domains, and is not practical to change. Only parameters that are known to libvirt will be preserved.
Opps, hit submit too soon. Meant to add, that if there are specific config parameters you would like to use, then please file individual BZ tickets for each config parameter, and they can be evaluated for inclusion. Some things are practical to support, some aren't, so we need to consider each config parameter individually as a feature request.
OK, I will file those bugs. Just for the record: I still think this is a bug because: 1) /etc/xen/* are xen config files, not libvirt's or virt-manager's. Upper layer (frontend) should not mess with configs from lower layers. 2) man xmdomain.cfg neither denys usage of custom options nor it states that only listed ones are valid 3) xen is perfectly fine with custom options, does not complain when called with custom options nor logs any warnings.
I accept that its a bug - its simply one we cannot fix. The Xen configs files are a horrific mess - they're not actually config files at all, but python scripts. XenD provides no capability for reading or writing these configs, and thus libvirt has to do it itself, and is limited to the config params it understands. This is all dead code, upstream having changed the way XenD manages inactive guests, to get rid of config files. To change the way we deal with this is simply not practical for a stable RHEL-5.x update, hence while this is a bug, it is not one we will fix
I see, thanks for the additional explanation.