VM disk size problem on deploy

About this code, Is it normal after performing the unset not to initialize the indexes i and j?

That is strange… Could you try to run the command manually as the oneadmin user?

su - oneadmin -c 'onevm show -x 4635'

Maybey there are some credentials issues popped after the upgrade…

Yes it is OK, BASH is using them as indexes of the XPATH_ELEMENTS array.

Hello again Anton,

I can execute the command as oneadmin without problems. Do you need the command output?

su - oneadmin -c 'onevm show -x 4635'
<VM>
  <ID>4635</ID>
  <UID>21</UID>
  <GID>0</GID>
...
      <ACTION>0</ACTION>
      <UID>-1</UID>
      <GID>-1</GID>
      <REQUEST_ID>-1</REQUEST_ID>
    </HISTORY>
  </HISTORY_RECORDS>
</VM>

Well,
If there are SIZE and ORIGINAL_SIZE elements in the disks there is nothing to look for.
The question is why this command is empty when called by opennebula?!

Long shot, but let’s try to catch the stderr too:

done < <(onevm show -x $VMID 2>/tmp/vm-${VMID}-${DISK_ID}.err| tee /tmp/vm-${VMID}-${DISK_ID}.xml | $XPATH \

I hope there will be some error logged in the file …

Best,
Anton

1 Like

Hi again Anton,

Thanks to the error dump I can think that I have a problem with ruby versions.

Different versions coexist in the system (OpenNebula, Chef). I have made sure that the gems have been installed for the version that will be used by OpenNebula (2.5.1) and that it is the default version for the oneadmin user.

In addition, I have modified the OpenNebula daemon configuration scripts as follows to force use of that ruby version.

Environment=GEM_HOME=/usr/local/rvm/gems/ruby-2.5.1
Environment=GEM_PATH=/usr/local/rvm/gems/ruby-2.5.1:/usr/local/rvm/gems/ruby-2.5.1@global
Environment=PATH=/usr/local/rvm/gems/ruby-2.5.1/bin:/usr/local/rvm/gems/ruby-2.5.1@global/bin:/usr/local/rvm/rubies/ruby-2.5.1/bin:/usr/local/rvm/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin 
ExecStart=/usr/local/rvm/rubies/ruby-2.5.1/bin/ruby /usr/lib/one/sunstone/sunstone-server.rb

This had worked for previous versions of OpenNebula.

The following error appears in the file with the error dump of the standard output:

/usr/local/rvm/gems/ruby-2.5.1/gems/nokogiri-1.6.8.1/lib/nokogiri.rb:124: [BUG] Segmentation fa
ult
ruby 2.0.0p598 (2014-11-13) [x86_64-linux]

Ruby version 2.0.0 is the one that installs the system by default, and the one that Chef uses.

Where do you think I made the mistake when setting up the demons to use the wrong version of Ruby? Will the modification in the scripts of the demons have stopped working?

I can attach the complete segmentation fault error that occurs when the VM is instantiated.

Thanks again for your time and effort.

I am not expert in Ruby so could not be of help on this topic. :confused: You could try to re-check are there gems that need to be updated or for new dependencies to be installed.

Best Regards,
Anton Todorov

Hello again Anton,

Thank you very much for your time and support.

I will keep trying to debug the problem and rephrase the question now that it seems to be a problem with the ruby version.

Best Regards,
Víctor Juidias

Hello again,

I finally found the problem.

It was a problem with the ruby version. Specifically, it was because the configuraion file for opennebula daemon had also been modified in /lib/systemd/system/opennebula.service to use the ruby version installed using rvm.

This configuration file for the demon should not be modified, only those of the demons such as opennebula-sunstone.service, opennebula-flow.service, etc.

Once the changes in this file were undone everything has returned to work as expected.

Thanks especially to @atodorov_storpool and @cgonzalez.

1 Like