Daniel P. Berrange wrote: >> (qemu) info block >> ide0-hd0: type=hd removable=0 file=/root/images/marcelo5.img ro=0 drv=raw >> ide1-cd0: type=cdrom removable=1 locked=0 [not inserted] >> floppy0: type=floppy removable=1 locked=0 [not inserted] >> sd0: type=floppy removable=1 locked=0 [not inserted] >> scsi0-hd0: type=hd removable=0 file=/tmp/bigfile ro=0 drv=raw >> scsi0-hd1: type=hd removable=0 file=/tmp/bigfile.2 ro=0 drv=raw >> >> (qemu) info network >> VLAN 0 devices: >> tap: ifname=tap0 setup_script=qemu-ifup-tap0 >> rtl8139 pci macaddr=52:54:00:12:34:56 >> > > This is utterly horrible for a human to parse & use if they're using the > QEMU monitor, let alone something that libvirt could parse. In fact this > doesn't let you map between the network device & pci device if there is > more than one device added because 'info pci' doesn't show the MAC address > info, and 'info network' does not show any PCI device number info - the > same for disks. > >
We need a machine friendly protocol for libvirt and other management tools. Versioned commands (with some backward compatibility), command discovery, and command/response tagging so you can associate an async reply to the command that triggered it, and quoting so that strings with spaces and other special chars are properly supported. But how the information is presented is orthogonal to what information is presented. btw, the qemu command line parses something fairly similar, I don't see why libvirt should have problems with it. It wouldn't be fun to code, but is doable. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
