Re: [Libvirt-cim] [PATCH 0 of 3] (#3) [RFC] Add external migration checks

HE> I looked a bit through the Migration Profile and found a class HE> that I suggest to use for this functionality. That's the HE> description of this class: "CIM_VirtualSystemMigrationSettingData HE> defines the parameters to control a virtual system migration HE> implementation, as managed by a HE> CIM_VirtualSystemMigrationService. It is expected that a migration HE> implementation will subclass this class to add HE> implementation-specific migration options." An instance of this HE> class is transported to all CheckIsVSMigratable...() and HE> MigrateVSTo...() via the MigrationSettingData parameter. So we HE> stay absolutely conform to the Migration Profile. The Xen and KVM HE> subclasses can check properties, that are well know to cause HE> migration problems. This is what I did. I extended Xen_MigrationSettingData to include the CheckParameters[] property, which is what I pass to the check program. There are no additional arguments to either of the CIM methods, and this extra property of the SettingData is optional. HE> Your approach of letting the client parameterize scripts through HE> this class might look like this: [Description("An array containing HE> the scripts to be executed as part of the check, if the migration HE> is possible.")] string ScriptsToExecute[]; [Description("An array HE> containing the parameters given as input to the scripts defined by HE> ScriptsToExecute. Each entry in this array is related to the same HE> array entry in ScriptToExecute. A list of parameters for one HE> script is divided by space characters.")] string HE> ScriptsParameterList[]; Choosing the external checks to run does two things: (1) It means that the client must know which checks are available on the host, and (2) it means that the client must change if the system administrator changes the name of the check on disk. Giving the client visibility and control over what we run and where seems to (1) be more of a security risk, and (2) be too specific. What I have now is less of "run command A with argument B" and more of "Here is some information I have that should help determine if a migration can succeed". I think that the latter is more generally applicable. However, if others feel strongly, we can change this to a list of programs and a list of arguments. Thanks Heidi! -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms(a)us.ibm.com