5 Replies Latest reply on Feb 16, 2012 7:58 AM by hesco

    Can't get vim_service - the session object is uninitialized or not logged in…

    cw2 Novice

      Like several other users on the original ghetto backup site http://communities.vmware.com/docs/DOC-9843;jsessionid=5669AAFCA462447AD165373B473A452C  I'm getting an error:

       

      Can't get vim_service - the session object is uninitialized or not logged in …

       

      In a previous virtual world I had this backup system working (that was with esxi 4.0 and NFS storage).  I'm now in another virtual world with esxi 4.1, iSCSI and NFS storage.

       

      I understand that the problem seems to lie with adding the servers.  Like user minerat back in Oct 2010 I added the servers and confirmed with  sudo vifp listservers.  For the hell of it I removed and re-added.  The  problem persists interactively even as vi-admin.

       

      Does anyone have some details of a fix for this problem - or failing that some ideas for debugging.

       

      ghettoVCBg2 is a great free product when it's working!

        • 1. Re: Can't get vim_service - the session object is uninitialized or not logged in…
          lamw Guru
          Community WarriorsVMware Employees

          Hi cw2,

           

          I've not ran into this issue before, unfortunately the error is some what generic, it just means that it was unable to get access to the vim_service which could be a bad hosts or it somehow disconnected and lost the session. I know it doesn't give you a clear reason why it bombed out, but somethings I would double check is to make sure your ESX(i) hosts during this backup had no issues and that all targets being managed by your vMA is accessible. I know in the past users may have stale targets and this could have led to some issues.

           

          Looking at @minerat comments, it looks like he had identified this isuse when using VM_SNAPSHOT_MEMORY to 1 but I've just quickly verified in my deveopment environment on 4.1 and I did not run into any such issue. I'm curious if you have the same configured in your environment? Another thing you could look at is during the start of your backup, launch a vSphere Client to your ESX(i) host and monitor the list of tasks and see if there's any failure during the workflow, specifically around the snapshoting process.

           

          I would also like to understand your a environment a bit more, if you can take a look at the FAQ found here - http://communities.vmware.com/groups/ghettovcbg2 and provide some additional details it would help, since the error message is too generic at this point.

           

          Thanks

          • 2. Re: Can't get vim_service - the session object is uninitialized or not logged in…
            cw2 Novice

            Well, to answer my own question…

             

            It was nothing to do with vifp and whether it's logged in or not (it was anyway).

             

            I was making the mistake (is this a mistake?) of trying to make a backup from one datastore to another.

             

            Changed to using the same datastore and then a post-backup copy and everything is ok

            • 3. Re: Can't get vim_service - the session object is uninitialized or not logged in…
              lamw Guru
              VMware EmployeesCommunity Warriors

              Could you provide a little more detail? What do you mean by making a backup from one datastore to another? As long as the ESX(i) host can see both source a destination datastores, it'll be able to create a backup. You won't be able to do backups to a datastore that is not acessible to a given ESX(i) host, does that make sense?

              • 4. Re: Can't get vim_service - the session object is uninitialized or not logged in…
                cw2 Novice

                4 blades each running licenses esxi 4.1

                Each has 2 datastores setup; one is NFS, the other is iSCSI

                Each blade can see both datastores

                Each blade can access any datastore as mapped.

                 

                Whether it's some other problem or not - backup to same datastore is ok, backup from iSCSI to NFS datastore produced the vim_service error.

                 

                Possibly some datastore compatibility/matching problem, or maybe some slow network connection to nfs, but in any case it's better to backup to the faster datastore and then move it around.

                 

                There's not enough debug info to work out what the vim_service is and whether or not it's initialized.

                 

                I'm just trying to get my VMs out the the iSCSI SAN so that they can be backed up onto some other media.  Obvious alternatives are paid-for solutions, but I need something free at the moment.

                • 5. Re: Can't get vim_service - the session object is uninitialized or not logged in…
                  hesco Novice

                  I'm not using ghettoVCBg2, don't know what it is or why it might be named that.  But I did encounter this error when invoking a ->MigrateVM_Task() method.  I went in to VMware::VICommon->invoke() and added two lines reading:

                   

                  print "VMware::VICommon line 1688 says: \n" . Data::Dumper::Dumper( (ref $self), $method, \%args, $ENV{'VI_SESSIONFILE'} );
                  print Data::Dumper::Dumper( $self->{vim} );

                   

                  which generated this output:

                   

                   

                  VMware::VICommon line 1688 says:

                  $VAR1 = 'VirtualMachine';

                  $VAR2 = 'MigrateVM_Task';

                  $VAR3 = {

                            'host' => bless( {

                                               'type' => 'HostSystem',

                                               'value' => 'host-28'

                                             }, 'ManagedObjectReference' ),

                            'priority' => 'defaultPriority',

                            'state' => bless( {

                                                'val' => 'poweredOn'

                                              }, 'VirtualMachinePowerState' )

                          };

                  $VAR4 = '/tmp/winvps/session_vsphere_1329173691';

                  $VAR1 = bless( {

                                   '_logout_on_disconnect' => 1,

                                   'service_content' => undef,

                                   'service_url' => 'https://our.vsphere.center.public.host:443/sdk/vimService',

                                   'vim_service' => undef

                                 }, 'Vim' );

                   

                   

                  The session file was less than two minutes old.  I'm told those sessions are good for thirty minutes or until deleted, so I doubt that was the issue.

                   

                  But my point is two fold:

                   

                  (1) to the previous poster who decried the lack of useful debugging information available, sometimes you just have to go in and add your own debugging;

                   

                  and

                   

                  (2)  'vim_service' => undef is returned in my Vim object dump and I wonder why that might be.  If I have a fresh session, why would the vim_service be undefined?