libvirt-cim-bounces(a)redhat.com wrote on 2008-01-31 18:55:30:
> Guo Lian Yun wrote:
> >
> > libvirt-cim-bounces(a)redhat.com wrote on 2008-01-30 21:48:16:
> >
> > > Guo Lian Yun wrote:
> > > >
> > > > Hi,
> > > >
> > > > The key name of instanceid is not case sensitive in ein or gi
> > operation.
> > > > Generally, it's written by "InstanceID" in querying
result, but
> > > > Virt_MigrationJob
> > > > instance is different, the ein output as following:
> > > > ...
> > > >
localhost:5988/root/virt:Virt_MigrationJob.instanceid="48814722-
> > > f6d7-4ba5-b2db-6bf3242bd281"
> > > > localhost:5988/root/virt:Virt_MigrationJob.
> > > instanceid="36529c45-8aed-425e-ad57-7f411b79d898"
> > > > ...
> > > >
> > > > I know it's a small problem, do you think we need to make it
identify
> > > > with other instances?
> > > >
> > > >
> > > > Best,
> > > > Regards
> > > >
> > > > Daisy Guo Lian Yun
> > > > E-mail: yunguol(a)cn.ibm.com
> > > > IBM China Development Lab, Shanghai, China
> > > > TEL: (86)-21-61008057
> > > >
> > > >
> > > Looking through the code I can't find anywhere where we set
InstanceID
> > > using all lowercase like that. Could you provide the exact
steps you
> > > did to get this so I can reproduce it?
> > >
> > >
> >
> > I get it by migration test. The steps are as followings:
> >
> > 1) Create and start a domain
> > 2) Call MigrateVirtualSystemToHost
> >
> > ret = service.MigrateVirtualSystemToHost(ComputerSystem=cs_ref,
> > DestinationHost=options.ip)
> >
> > 3) Once the migration started, you can get Virt_MigrationJob instance.
> > Get the Job ID from the result of MigrateVirtualSystemToHost,
> > and then monitor the Xen_MigrationJob instance to see when it
> > finishes,
> > which can be got on the other console by ein and gi.
> >
> >
> > wbemcli ein
http://root:password@localhost/root/virt:Virt_MigrationJob
> > localhost:5988/root/virt:Virt_MigrationJob.
> instanceid="2eb7e2ca-6197-4e50-9590-7cd05064d242"
> >
> > wbemcli gi
> >
http://root:password@localhost/root/virt:Virt_MigrationJob.instanceid=
> "2eb7e2ca-6197-4e50-9590-7cd05064d242"
> > localhost:5988/root/virt:Virt_MigrationJob.
> instanceid="2eb7e2ca-6197-4e50-9590-7cd05064d242"
> >
> > OtherRecoveryAction,RecoveryAction,ErrorDescription,ErrorCode,
> DeleteOnCompletion=TRUE,PercentComplete,Priority,Owner,Notify,
> UntilTime,LocalOrUtcTime,RunStartInterval,RunDayOfWeek,RunDay,
> RunMonth,JobRunTimes=1,ElapsedTime,StartTime=20080131123445.
> 522288+480,ScheduledStartTime,TimeSubmitted,JobStatus,
> CommunicationStatus,OperatingStatus,DetailedStatus,PrimaryStatus,
> HealthState,Status="Migration
> > Failed",StatusDescriptions,OperationalStatus,InstallDate,Caption,
> Description,ElementName,
>
InstanceID="2eb7e2ca-6197-4e50-9590-7cd05064d242",Name="Migration",
>
JobState=7,TimeOfLastStateChange,TimeBeforeRemoval=00000000000500.000000:000
> >
> >
> Well, the background is that the instance provider for
Virt_MigrationJob
> is none of our providers. I found no implementation nor a registration
> of one provider for Virt_MigrationJob (as Jay already mentioned). But
> within the code you can find calls back to the CIMOM, that do
> createInstance(), modifyInstance() and deleteInstance() on the
> Virt_MigrationJob instances. This can only mean, that the
instance(s) of
> Virt_MigrationJob are stored in the CIMOM's repository (where also the
> schema is located) and are handled by Pegasus' internal provider. And
> this internal provider is responsible for setting the "instanceid". So
> now I can only suppose ... the provider is setting "instanceid" instead
> of "InstanceID" for ein calls. One interesting test case would be doing
> the gi with the uppercase notation. Please can you provide me this
> result ? Thanks.
>
> wbemcli gi
>
http://root:password@localhost/root/virt:Virt_MigrationJob.InstanceID=
> <
http://root:password@localhost/root/virt:Virt_MigrationJob.instanceid=
> >"2eb7e2ca-6197-4e50-9590-7cd05064d242"
>
Below are the outputs of ein and gi with the uppercase notation.
wbemcli ein
http://root:password@localhost/root/virt:Virt_MigrationJob
localhost:5988/root/virt:Virt_MigrationJob.instanceid="066259d5-4c5a-4b1f-991f-0d839f105a68"
wbemcli gi
http://root:password@localhost/root/virt:Virt_MigrationJob.InstanceID=&qu...
localhost:5988/root/virt:Virt_MigrationJob.InstanceID="066259d5-4c5a-4b1f-991f-0d839f105a68"
OtherRecoveryAction,RecoveryAction,ErrorDescription,ErrorCode,DeleteOnCompletion=TRUE,PercentComplete,Priority,Owner,Notify,UntilTime,LocalOrUtcTime,RunStartInterval,RunDayOfWeek,RunDay,RunMonth,JobRunTimes=1,ElapsedTime,StartTime=20080201081420.535009+480,ScheduledStartTime,TimeSubmitted,JobStatus,CommunicationStatus,OperatingStatus,DetailedStatus,PrimaryStatus,HealthState,Status="Running",StatusDescriptions,OperationalStatus,InstallDate,Caption,Description,ElementName,InstanceID="066259d5-4c5a-4b1f-991f-0d839f105a68",Name="Migration",JobState=4,TimeOfLastStateChange,TimeBeforeRemoval=00000000000500.000000:000
Also, the output of gi with the lowercase notation as follows:
wbemcli gi
http://root:password@localhost/root/virt:Virt_MigrationJob.instanceid=&qu...
localhost:5988/root/virt:Virt_MigrationJob.instanceid="066259d5-4c5a-4b1f-991f-0d839f105a68"
OtherRecoveryAction,RecoveryAction,ErrorDescription,ErrorCode,DeleteOnCompletion=TRUE,PercentComplete,Priority,Owner,Notify,UntilTime,LocalOrUtcTime,RunStartInterval,RunDayOfWeek,RunDay,RunMonth,JobRunTimes=1,ElapsedTime,StartTime=20080201081420.535009+480,ScheduledStartTime,TimeSubmitted,JobStatus,CommunicationStatus,OperatingStatus,DetailedStatus,PrimaryStatus,HealthState,Status="Running",StatusDescriptions,OperationalStatus,InstallDate,Caption,Description,ElementName,InstanceID="066259d5-4c5a-4b1f-991f-0d839f105a68",Name="Migration",JobState=4,TimeOfLastStateChange,TimeBeforeRemoval=00000000000500.000000:000
Ok, now I have cleared up my mind. Pegasus' internal provider sets
"instanceid" lowercase for ein (please don't ask me why) and short term
we have no possibility to change this. Long term we can go back into the
Pegasus community and ask them to use the DMTF given uppercase notation.
But that would take a while.
For the different object pathes on the gi call wbemcli itself is
responsible. Only for informational purpose wbemcli is - in addition to
the providers instance - printing the request's object path again. This
object path was not generated by the provider.
That's all I can tell to this issue.
--
Regards
Heidi Eckhart
Software Engineer
IBM Linux Technology Center - Open Hypervisor