> > This is just one reason why I don't like the idea of simply running shell > > scripts in the back end. This will result in a unreliable, hard-to debug > > system. It may be a short term win on implementation speed, but it will be > > a PITA for long term maintainence. One thing you will immediately get is > > people writing scripts which add all kinda of custom crap to the XML > > destroying the benefit of libvirt which is the standardization. For any > > I don't understand this. Scripts can be written which add custom fields > to the XML, but since libvirt will just ignore those fields I don't see > any issue. > > > given storage backend, we know what operations we need to be able to > > perform & so we have a finite set of commands we need to run with known > > predictable arguments. We just don't need the 'flexibility' of running > > arbitrary shell scripts & XML filters in the backend end. > > We do because we need to be able to take the output of 'vgs', 'sfdisk', > 'iscsiadm', etc., the output of each being essentially the same > information (a list of volume groups plus the size and free space of > each), and present that information in the same format back to libvirt. > In this case a common format makes perfect sense. It need not be XML, > it might be CSV, but in this case XML's extensibility makes sense, along > with the fact that libvirt already parses XML. > > (Note for people snoozing through this email, we're talking about two > different uses of XML). (Sorry if irrelevant...) Because "The XML should be mentioned minimum management information", I think that it is better to be only frontdev, backdev, type and a kind of the device as now. Information except it should be examined with these as materials anytime by storage API. ( May not matter, When I'm thinking about "Bugzilla Bug 329091: [5.2]The disk which the OS is in...", I thought that "storage API" was such a thing...) Shigeki Sakamoto. -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list