[libvirt] RFC: virt-xml: command line tool for altering guest configuration

Hi all, Attached is a patch to virtinst.git that provides a new tool named virt-xml. virt-xml provides a scriptable command line interface for editing libvirt guest XML. A couple examples: Change boot order and boot menu for 'myguest': $ ./virt-xml --guest myguest --boot network,hd,cdrom,menu=on Requested changes: --- Original XML +++ New XML @@ -10,6 +10,8 @@ <os> <type arch="i686">hvm</type> <loader>/usr/lib/xen/boot/hvmloader</loader> + <boot dev="network"/> + <bootmenu enable="yes"/> <boot dev="hd"/> + <boot dev="cdrom"/> </os> <features> <acpi/> Change disk #7 to use cache=none for 'myguest': $ ./virt-xml --guest myguest --device 7 --disk cache=none Requested changes: --- Original XML +++ New XML @@ -74,6 +74,7 @@ <disk type="file" device="disk"> <source file="/tmp/foobar3"/> <target dev="sdd" bus="usb"/> + <driver cache="none"/> </disk> <disk type="file" device="disk"> <driver name="tap" type="qcow" cache="writethrough"/> Change watchdog action for 'myguest': $ ./virt-xml --guest myguest --device 1 --watchdog action=pause Requested changes: --- Original XML +++ New XML @@ -220,7 +220,7 @@ <address domain="0x0003" bus="0x00" slot="0x19" function="0x0"/> </source> </hostdev> - <watchdog model="ib700" action="poweroff"/> + <watchdog model="ib700" action="pause"/> <memballoon model="xen"/> </devices> </domain> --boot, --disk, and --watchdog come straight from virt-install, see man virt-install for detailed docs of the option format. Those options shown are the only things wired up right now, but it's a straightforward task to wire up most of the relevant remaining virt-install opts. Also the tool doesn't actually apply the changes yet, but that is also a trivial addition. I think the interesting bit here is nailing down the scope of the tool and deciding on good CLI syntax. Not sure if we should do hotplug/hotunplug as a subcommand or just another option like: virt-xml ... --hotplug --disk /tmp/foo.img Also not really sure how to hotunplug using the --device syntax of the above examples: virt-xml ... --hotunplug --device 1 --disk <what goes here?> We could make --device just an option to whatever device string the user gives virt-xml ... --hotunplug --disk id=1 We can easily allow different XML input methods like: virt-xml --guestxml file.xml ... or even batch processing virt-xml --guest * ... Maybe even have allow more intelligence about what guests we edit, say we want to set cache=none for all disk devices, not CDROM or floppy (this would take a bit of work to sort out). virt-xml --guest * --disk match,device=disk --disk cache=none Then there is also the question of extending the tool to also edit other XML like storage, network, interface, etc. Any recommendations appreciated: option syntax, future capabilities, or even a better name for the tool :) A quick word about why I think we should do this with a separate tool rather than virsh. For starters, I think the need for this functionality on the command line is clear by now, so it's just a question of where to implement it. Why not virsh? Text and command line processing in C is a serious pain compared to a higher level language like python. I don't think this is a controversial statement, in fact I think it's partly responsible for why the virsh XML building commands have typically been in a pretty sorry state. virsh could conceivably use the internal domain_conf API to make this task much easier, but it would still require a lot of command line options for every XML parameter. In contrast, virt-install already needs to do most of this command line processing, and virt-manager needs to do all the XML building, parsing, and editing. Since this code already lives in one place (virtinst), it's almost trivial for us to reuse it. Supporting a new XML property on the command line is a very simple task and will immediately benefit both virt-install and virt-xml. We also already have over 75% of the domain XML schema available via existing CLI options that are already documented :) Questions or comments appreciated! Thanks, Cole