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=&qu...
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
--
Regards
Heidi Eckhart
Software Engineer
IBM Linux Technology Center - Open Hypervisor