Problem with showing VMs with foreman-1.5.1 and oVirt-3.4.2

Support
1

As per subject I seem to have a problem between oVirt and Foreman. Setup
is a clean install of foreman-1.5.1 on Centos-6.5 and I have 2 compute
resources defined:

  • oVirt-Prod is connected to our production env containing 105 VMs
  • oVirt-Test is connected to our test env containing around 30 VMs
    Both envs are running oVirt-3.4.2.

The problem is that selecting the prod CR won't show any VM's only an
error msg: There was an error listing VMs: undefined method `[]' for
nil:NilClass
Doing the same for our test env will show all VM's
I turned on debug logging for foreman and found the following interesting:
First the log of Test:

Started GET "/compute_resources/2-ovirt-test/vms" for 192.168.216.236 at 2014-06-24 21:47:48 +0200

Processing by ComputeResourcesVmsController#index as HTML

Parameters: {"compute_resource_id"=>"2-ovirt-test"}

e[1me[35mUser Load (0.5ms)e[0m SELECT "users".* FROM "users" WHERE "users"."id" = $1 LIMIT 1 [["id", 1]]

Setting current user thread-local variable to admin

e[1me[36mComputeResource Load (0.4ms)e[0m e[1mSELECT "compute_resources".* FROM "compute_resources" WHERE "compute_resources"."id" = $1 ORDER BY compute_resources.name LIMIT 1e[0m [["id", "2-ovirt-test"]]

Successfully decrypted field for Foreman::Model::Ovirt oVirt-Test

Rendered compute_resources_vms/index/_ovirt.html.erb (793.1ms)

Rendered compute_resources_vms/index.html.erb within layouts/application (795.5ms)

Rendered home/_user_dropdown.html.erb (1.8ms)

Read fragment views/tabs_and_title_records-1 (0.2ms)

Rendered home/_topbar.html.erb (3.2ms)

Rendered layouts/base.html.erb (5.1ms)

Completed 200 OK in 2770ms (Views: 805.4ms | ActiveRecord: 0.9ms)

Second of Prod:

Started GET "/compute_resources/1-ovirt-prod/vms" for 192.168.216.236 at 2014-06-24 21:49:04 +0200
Processing by ComputeResourcesVmsController#index as HTML
Parameters: {"compute_resource_id"=>"1-ovirt-prod"}
e[1me[35mUser Load (0.4ms)e[0m SELECT "users".* FROM "users" WHERE "users"."id" = $1 LIMIT 1 [["id", 1]]
Setting current user thread-local variable to admin
e[1me[36mComputeResource Load (0.3ms)e[0m e[1mSELECT "compute_resources".* FROM "compute_resources" WHERE "compute_resources"."id" = $1 ORDER BY compute_resources.name LIMIT 1e[0m [["id", "1-ovirt-prod"]]
Successfully decrypted field for Foreman::Model::Ovirt oVirt-Prod

Started GET "/compute_resources/1-ovirt-prod/images" for 192.168.216.236 at 2014-06-24 21:49:04 +0200

Notice the absence of two renderings.
I would like to debug this further but https is making that difficult. I
would like to add some debug to one of the components that gets called
to find out what is being returned from oVirt that Foreman doesn't like
but my Ruby skills are not up to speed for that.

Any help appreciated,

Joop

2

> The problem is that selecting the prod CR won't show any VM's only an
> error msg: There was an error listing VMs: undefined method `[]' for
> nil:NilClass
> Doing the same for our test env will show all VM's
> I turned on debug logging for foreman and found the following interesting:
[snip]
> Second of Prod:
>
> Started GET "/compute_resources/1-ovirt-prod/vms" for 192.168.216.236 at 2014-06-24 21:49:04 +0200
> Processing by ComputeResourcesVmsController#index as HTML
> Parameters: {"compute_resource_id"=>"1-ovirt-prod"}
> [1m [35mUser Load (0.4ms) [0m SELECT "users".* FROM "users" WHERE "users"."id" = $1 LIMIT 1 [["id", 1]]
> Setting current user thread-local variable to admin
> [1m [36mComputeResource Load (0.3ms) [0m [1mSELECT "compute_resources".* FROM "compute_resources" WHERE "compute_resources"."id" = $1 ORDER BY compute_resources.name LIMIT 1 [0m [["id", "1-ovirt-prod"]]
> Successfully decrypted field for Foreman::Model::Ovirt oVirt-Prod
>
>
> Started GET "/compute_resources/1-ovirt-prod/images" for 192.168.216.236 at 2014-06-24 21:49:04 +0200
>
> Notice the absence of two renderings.
> I would like to debug this further but https is making that difficult. I
> would like to add some debug to one of the components that gets called
> to find out what is being returned from oVirt that Foreman doesn't like
> but my Ruby skills are not up to speed for that.

If you don't mind changing the source a bit, I'd start here:

app/controllers/compute_resources_vms_controller.rb

Try commenting out the "rescue => e" and "render" lines in the index
method at the top. This should allow the exception to be handled at a
different layer, so it gets logged with a stack trace (provided debug
logging is on).

Else you could try adding "logger.debug" calls into the rescue block.

··· On 24/06/14 23:03, jvandewege wrote:

–
Dominic Cleal
Red Hat Engineering

3

>> The problem is that selecting the prod CR won't show any VM's only an
>> error msg: There was an error listing VMs: undefined method `[]' for
>> nil:NilClass
>> Doing the same for our test env will show all VM's
>> I turned on debug logging for foreman and found the following interesting:
> [snip]
>> Second of Prod:
>>
>> Started GET "/compute_resources/1-ovirt-prod/vms" for 192.168.216.236 at 2014-06-24 21:49:04 +0200
>> Processing by ComputeResourcesVmsController#index as HTML
>> Parameters: {"compute_resource_id"=>"1-ovirt-prod"}
>> [1m [35mUser Load (0.4ms) [0m SELECT "users".* FROM "users" WHERE "users"."id" = $1 LIMIT 1 [["id", 1]]
>> Setting current user thread-local variable to admin
>> [1m [36mComputeResource Load (0.3ms) [0m [1mSELECT "compute_resources".* FROM "compute_resources" WHERE "compute_resources"."id" = $1 ORDER BY compute_resources.name LIMIT 1 [0m [["id", "1-ovirt-prod"]]
>> Successfully decrypted field for Foreman::Model::Ovirt oVirt-Prod
>>
>>
>> Started GET "/compute_resources/1-ovirt-prod/images" for 192.168.216.236 at 2014-06-24 21:49:04 +0200
>>
>> Notice the absence of two renderings.
>> I would like to debug this further but https is making that difficult. I
>> would like to add some debug to one of the components that gets called
>> to find out what is being returned from oVirt that Foreman doesn't like
>> but my Ruby skills are not up to speed for that.
> If you don't mind changing the source a bit, I'd start here:
>
> app/controllers/compute_resources_vms_controller.rb
>
> Try commenting out the "rescue => e" and "render" lines in the index
> method at the top. This should allow the exception to be handled at a
> different layer, so it gets logged with a stack trace (provided debug
> logging is on).
Done and this is the result (partial, assuming the first 2 lines are the
culprit)

Operation FAILED: undefined method []' for nil:NilClass /opt/rh/ruby193/root/usr/share/gems/gems/rbovirt-0.0.26/lib/ovirt/volume.rb:35:inparse_xml_attributes!'
/opt/rh/ruby193/root/usr/share/gems/gems/rbovirt-0.0.26/lib/ovirt/volume.rb:8:in
`initialize'

··· On 25-6-2014 12:29, Dominic Cleal wrote: > On 24/06/14 23:03, jvandewege wrote:

Else you could try adding “logger.debug” calls into the rescue block.

4

A bit of updating on this.

I instrumented part of rbovirt (volume.rb and vm.rb) with lots of
logger.debug statements and I know now that atleast something is happening.
Selecting my Prod-oVirt CR shows that a couple of VMs are read through
the api and then suddenly it stops. At first it stopped at the 10 or
11th VM and that happened to be the VM that is used for a template but
renaming it to 1Vm_name didn't stop at the first one. Renaming a few
more to Zxyz showed that 10 isn't a special case either. I'm now at the
12 or 13th VM before it stops. Still no clue as to why.

Anyone got a better idea to debug this?

(Created about 70 extra VMs in test, no problem there with 105 :frowning: )

Joop

5

OK, probably found it.

In Prod-oVirt we had VMs with disk which were direct luns, iscsi luns.
They are still in the system, either attached but inactive to VMs or as
unattached disks.
Seems that some attribute from those disk is crashing rbovirt.

I did a little cleanup on xml.inspect from volume.rb and result is below.

<Nokogiri::XML::Element:0x47b916c name="disk"

attributes=[#<Nokogiri::XML::Attr:0x450aeac name="href" value="/api/vms/efa0c18a-3c4c-44fd-9758-4bd25579f209/disks/555af736-81d6-4334-a187-33122f3e445a">,

#<Nokogiri::XML::Attr:0x450ae84 name="id" value="555af736-81d6-4334-a187-33122f3e445a">]

children=[#<Nokogiri::XML::Text:0x4783c10 "\n ">,

#<Nokogiri::XML::Element:0x4783850 name="actions" children=[#<Nokogiri::XML::Text:0x46d73d4 "\n ">,

#<Nokogiri::XML::Element:0x46d703c name="link" attributes=[#<Nokogiri::XML::Attr:0x46d6d08 name="href" value="/api/vms/efa0c18a-3c4c-44fd-9758-4bd25579f209/disks/555af736-81d6-4334-a187-33122f3e445a/deactivate">,

#<Nokogiri::XML::Attr:0x46d6bf0 name="rel" value="deactivate">]>,

#<Nokogiri::XML::Text:0x478da94 "\n ">,

#<Nokogiri::XML::Element:0x478d8a0 name="link" attributes=[#<Nokogiri::XML::Attr:0x478d800 name="href" value="/api/vms/efa0c18a-3c4c-44fd-9758-4bd25579f209/disks/555af736-81d6-4334-a187-33122f3e445a/activate">,

#<Nokogiri::XML::Attr:0x478d774 name="rel" value="activate">]>,

#<Nokogiri::XML::Text:0x47e4c54 "\n ">,

#<Nokogiri::XML::Element:0x47e49d4 name="link" attributes=[#<Nokogiri::XML::Attr:0x47e47b8 name="href" value="/api/vms/efa0c18a-3c4c-44fd-9758-4bd25579f209/disks/555af736-81d6-4334-a187-33122f3e445a/export">,

#<Nokogiri::XML::Attr:0x47e4790 name="rel" value="export">]>,

#<Nokogiri::XML::Text:0x47f82e0 "\n ">,

#<Nokogiri::XML::Element:0x47f7b10 name="link" attributes=[#<Nokogiri::XML::Attr:0x47f7804 name="href" value="/api/vms/efa0c18a-3c4c-44fd-9758-4bd25579f209/disks/555af736-81d6-4334-a187-33122f3e445a/move">,

#<Nokogiri::XML::Attr:0x47f77b4 name="rel" value="move">]>,

#<Nokogiri::XML::Text:0x48097fc "\n ">]>,

#<Nokogiri::XML::Text:0x4808adc "\n ">,

#<Nokogiri::XML::Element:0x47b81f4 name="name" children=[#<Nokogiri::XML::Text:0x4813e8c "doc01_Disk1">]>,

#<Nokogiri::XML::Text:0x481357c "\n ">,

#<Nokogiri::XML::Element:0x4812f00 name="link" attributes=[#<Nokogiri::XML::Attr:0x4812bf4 name="href" value="/api/vms/efa0c18a-3c4c-44fd-9758-4bd25579f209/disks/555af736-81d6-4334-a187-33122f3e445a/permissions">,

#<Nokogiri::XML::Attr:0x4812bb8 name="rel" value="permissions">]>,

#<Nokogiri::XML::Text:0x48205b0 "\n ">,

#<Nokogiri::XML::Element:0x482022c name="link" attributes=[#<Nokogiri::XML::Attr:0x4820100 name="href" value="/api/vms/efa0c18a-3c4c-44fd-9758-4bd25579f209/disks/555af736-81d6-4334-a187-33122f3e445a/statistics">,

#<Nokogiri::XML::Attr:0x48200ec name="rel" value="statistics">]>,

#<Nokogiri::XML::Text:0x481e968 "\n ">,

#<Nokogiri::XML::Element:0x4824930 name="vm" attributes=[#<Nokogiri::XML::Attr:0x4824854 name="href" value="/api/vms/efa0c18a-3c4c-44fd-9758-4bd25579f209">,

#<Nokogiri::XML::Attr:0x4824818 name="id" value="efa0c18a-3c4c-44fd-9758-4bd25579f209">]>,

#<Nokogiri::XML::Text:0x474ae4c "\n ">,

#<Nokogiri::XML::Element:0x474acbc name="alias" children=[#<Nokogiri::XML::Text:0x4521198 "doc01_Disk1">]>,

#<Nokogiri::XML::Text:0x45206d0 "\n ">,

#<Nokogiri::XML::Element:0x4520068 name="interface" children=[#<Nokogiri::XML::Text:0x45020f4 "virtio">]>,

#<Nokogiri::XML::Text:0x4501898 "\n ">,

#<Nokogiri::XML::Element:0x4501514 name="bootable" children=[#<Nokogiri::XML::Text:0x4500a74 "false">]>,

#<Nokogiri::XML::Text:0x4696820 "\n ">,

#<Nokogiri::XML::Element:0x4696460 name="shareable" children=[#<Nokogiri::XML::Text:0x469608c "false">]>,

#<Nokogiri::XML::Text:0x4695a88 "\n ">,

#<Nokogiri::XML::Element:0x46957a4 name="wipe_after_delete" children=[#<Nokogiri::XML::Text:0x46874d8 "false">]>,

#<Nokogiri::XML::Text:0x4686a4c "\n ">,

#<Nokogiri::XML::Element:0x468618c name="propagate_errors" children=[#<Nokogiri::XML::Text:0x4685a70 "false">]>,

#<Nokogiri::XML::Text:0x439e668 "\n ">,

#<Nokogiri::XML::Element:0x439e280 name="active" children=[#<Nokogiri::XML::Text:0x439d934 "false">]>,

#<Nokogiri::XML::Text:0x439d2e0 "\n ">,

#<Nokogiri::XML::Element:0x40cf2ac name="read_only" children=[#<Nokogiri::XML::Text:0x40cee24 "false">]>,

#<Nokogiri::XML::Text:0x40ce938 "\n ">,

#<Nokogiri::XML::Element:0x40ce7e4 name="lun_storage" attributes=[#<Nokogiri::XML::Attr:0x40ce730 name="id" value="36090a01840ec6ccb8be664f48b00e04c">]

children=[#<Nokogiri::XML::Text:0x4654038 "\n ">,

#<Nokogiri::XML::Element:0x4653a0c name="logical_unit" attributes=[#<Nokogiri::XML::Attr:0x46538f4 name="id" value="36090a01840ec6ccb8be664f48b00e04c">]

children=[#<Nokogiri::XML::Text:0x4652bc0 "\n ">,

#<Nokogiri::XML::Element:0x4652850 name="serial" children=[#<Nokogiri::XML::Text:0x4865afc "SEQLOGIC_100E-00_6090A01840EC6CCB8BE664F48B00E04C">]>,

#<Nokogiri::XML::Text:0x486541c "\n ">,

#<Nokogiri::XML::Element:0x4865278 name="vendor_id" children=[#<Nokogiri::XML::Text:0x4864f94 "EQLOGIC">]>,

#<Nokogiri::XML::Text:0x4864b34 "\n ">,

#<Nokogiri::XML::Element:0x48649b8 name="product_id" children=[#<Nokogiri::XML::Text:0x4864508 "100E-00">]>,

#<Nokogiri::XML::Text:0x4504ea8 "\n ">,

#<Nokogiri::XML::Element:0x4504c3c name="lun_mapping" children=[#<Nokogiri::XML::Text:0x4504340 "0">]>,

#<Nokogiri::XML::Text:0x4503b5c "\n ">,

#<Nokogiri::XML::Element:0x45038f0 name="size" children=[#<Nokogiri::XML::Text:0x468b8e4 "10737418240">]>,

#<Nokogiri::XML::Text:0x468b380 "\n ">,

#<Nokogiri::XML::Element:0x468b1dc name="paths" children=[#<Nokogiri::XML::Text:0x468adb8 "0">]>,

#<Nokogiri::XML::Text:0x468a804 "\n ">,

#<Nokogiri::XML::Element:0x468a46c name="disk_id" children=[#<Nokogiri::XML::Text:0x468a0fc "555af736-81d6-4334-a187-33122f3e445a">]>,

#<Nokogiri::XML::Text:0x4689e18 "\n ">]>,

#<Nokogiri::XML::Text:0x48b343c "\n ">]>,

#<Nokogiri::XML::Text:0x48b2c30 "\n ">]>

6

I can confirm your findings. I too ran into the same issue with oVirt VMs using Direct LUNs via iSCSI and Foreman. At the time I was evaluating the performance benefit of Direct LUN vs VM images over iSCSI. In the end I chose images over Direct LUNs and forgot to file a bug report. I don't have any debug output as this was around the time of the oVirt 3.4 release, but thought I'd let you know your findings are correct.

  • Trey
7

Thanks Trey, I'll try to narrow it down today. I think the problem is in
the storagedomain.rb but need to inject some logger.debug statements to
make sure, I'll open a bug report on it.

Joop

··· On 26-6-2014 4:59, treydock wrote: > I can confirm your findings. I too ran into the same issue with oVirt VMs using Direct LUNs via iSCSI and Foreman. At the time I was evaluating the performance benefit of Direct LUN vs VM images over iSCSI. In the end I chose images over Direct LUNs and forgot to file a bug report. I don't have any debug output as this was around the time of the oVirt 3.4 release, but thought I'd let you know your findings are correct. > > - Trey >
8

> OK, probably found it.
>
> In Prod-oVirt we had VMs with disk which were direct luns, iscsi luns.
> They are still in the system, either attached but inactive to VMs or as
> unattached disks.
> Seems that some attribute from those disk is crashing rbovirt.
>
> I did a little cleanup on xml.inspect from volume.rb and result is below.
>
> <Nokogiri::XML::Element:0x47b916c name="disk"
>
> attributes=[#<Nokogiri::XML::Attr:0x450aeac name="href"
> value="/api/vms/efa0c18a-3c4c-44fd-9758-4bd25579f209/disks/555af736-81d6-4334-a187-33122f3e445a">,
>
> #<Nokogiri::XML::Attr:0x450ae84 name="id"
> value="555af736-81d6-4334-a187-33122f3e445a">]
>
> children=[#<Nokogiri::XML::Text:0x4783c10 "\n ">,
>
> #<Nokogiri::XML::Element:0x4783850 name="actions"
> children=[#<Nokogiri::XML::Text:0x46d73d4 "\n ">,
>
> #<Nokogiri::XML::Element:0x46d703c name="link"
> attributes=[#<Nokogiri::XML::Attr:0x46d6d08 name="href"
> value="/api/vms/efa0c18a-3c4c-44fd-9758-4bd25579f209/disks/555af736-81d6-4334-a187-33122f3e445a/deactivate">,
>
> #<Nokogiri::XML::Attr:0x46d6bf0 name="rel" value="deactivate">]>,
>
> #<Nokogiri::XML::Text:0x478da94 "\n ">,
>
> #<Nokogiri::XML::Element:0x478d8a0 name="link"
> attributes=[#<Nokogiri::XML::Attr:0x478d800 name="href"
> value="/api/vms/efa0c18a-3c4c-44fd-9758-4bd25579f209/disks/555af736-81d6-4334-a187-33122f3e445a/activate">,
>
> #<Nokogiri::XML::Attr:0x478d774 name="rel" value="activate">]>,
>
> #<Nokogiri::XML::Text:0x47e4c54 "\n ">,
>
> #<Nokogiri::XML::Element:0x47e49d4 name="link"
> attributes=[#<Nokogiri::XML::Attr:0x47e47b8 name="href"
> value="/api/vms/efa0c18a-3c4c-44fd-9758-4bd25579f209/disks/555af736-81d6-4334-a187-33122f3e445a/export">,
>
> #<Nokogiri::XML::Attr:0x47e4790 name="rel" value="export">]>,
>
> #<Nokogiri::XML::Text:0x47f82e0 "\n ">,
>
> #<Nokogiri::XML::Element:0x47f7b10 name="link"
> attributes=[#<Nokogiri::XML::Attr:0x47f7804 name="href"
> value="/api/vms/efa0c18a-3c4c-44fd-9758-4bd25579f209/disks/555af736-81d6-4334-a187-33122f3e445a/move">,
>
> #<Nokogiri::XML::Attr:0x47f77b4 name="rel" value="move">]>,
>
> #<Nokogiri::XML::Text:0x48097fc "\n ">]>,
>
> #<Nokogiri::XML::Text:0x4808adc "\n ">,
>
> #<Nokogiri::XML::Element:0x47b81f4 name="name"
> children=[#<Nokogiri::XML::Text:0x4813e8c "doc01_Disk1">]>,
>
> #<Nokogiri::XML::Text:0x481357c "\n ">,
>
> #<Nokogiri::XML::Element:0x4812f00 name="link"
> attributes=[#<Nokogiri::XML::Attr:0x4812bf4 name="href"
> value="/api/vms/efa0c18a-3c4c-44fd-9758-4bd25579f209/disks/555af736-81d6-4334-a187-33122f3e445a/permissions">,
>
> #<Nokogiri::XML::Attr:0x4812bb8 name="rel" value="permissions">]>,
>
> #<Nokogiri::XML::Text:0x48205b0 "\n ">,
>
> #<Nokogiri::XML::Element:0x482022c name="link"
> attributes=[#<Nokogiri::XML::Attr:0x4820100 name="href"
> value="/api/vms/efa0c18a-3c4c-44fd-9758-4bd25579f209/disks/555af736-81d6-4334-a187-33122f3e445a/statistics">,
>
> #<Nokogiri::XML::Attr:0x48200ec name="rel" value="statistics">]>,
>
> #<Nokogiri::XML::Text:0x481e968 "\n ">,
>
> #<Nokogiri::XML::Element:0x4824930 name="vm"
> attributes=[#<Nokogiri::XML::Attr:0x4824854 name="href"
> value="/api/vms/efa0c18a-3c4c-44fd-9758-4bd25579f209">,
>
> #<Nokogiri::XML::Attr:0x4824818 name="id"
> value="efa0c18a-3c4c-44fd-9758-4bd25579f209">]>,
>
> #<Nokogiri::XML::Text:0x474ae4c "\n ">,
>
> #<Nokogiri::XML::Element:0x474acbc name="alias"
> children=[#<Nokogiri::XML::Text:0x4521198 "doc01_Disk1">]>,
>
> #<Nokogiri::XML::Text:0x45206d0 "\n ">,
>
> #<Nokogiri::XML::Element:0x4520068 name="interface"
> children=[#<Nokogiri::XML::Text:0x45020f4 "virtio">]>,
>
> #<Nokogiri::XML::Text:0x4501898 "\n ">,
>
> #<Nokogiri::XML::Element:0x4501514 name="bootable"
> children=[#<Nokogiri::XML::Text:0x4500a74 "false">]>,
>
> #<Nokogiri::XML::Text:0x4696820 "\n ">,
>
> #<Nokogiri::XML::Element:0x4696460 name="shareable"
> children=[#<Nokogiri::XML::Text:0x469608c "false">]>,
>
> #<Nokogiri::XML::Text:0x4695a88 "\n ">,
>
> #<Nokogiri::XML::Element:0x46957a4 name="wipe_after_delete"
> children=[#<Nokogiri::XML::Text:0x46874d8 "false">]>,
>
> #<Nokogiri::XML::Text:0x4686a4c "\n ">,
>
> #<Nokogiri::XML::Element:0x468618c name="propagate_errors"
> children=[#<Nokogiri::XML::Text:0x4685a70 "false">]>,
>
> #<Nokogiri::XML::Text:0x439e668 "\n ">,
>
> #<Nokogiri::XML::Element:0x439e280 name="active"
> children=[#<Nokogiri::XML::Text:0x439d934 "false">]>,
>
> #<Nokogiri::XML::Text:0x439d2e0 "\n ">,
>
> #<Nokogiri::XML::Element:0x40cf2ac name="read_only"
> children=[#<Nokogiri::XML::Text:0x40cee24 "false">]>,
>
> #<Nokogiri::XML::Text:0x40ce938 "\n ">,
>
> #<Nokogiri::XML::Element:0x40ce7e4 name="lun_storage"
> attributes=[#<Nokogiri::XML::Attr:0x40ce730 name="id"
> value="36090a01840ec6ccb8be664f48b00e04c">]
>
> children=[#<Nokogiri::XML::Text:0x4654038 "\n ">,
>
> #<Nokogiri::XML::Element:0x4653a0c name="logical_unit"
> attributes=[#<Nokogiri::XML::Attr:0x46538f4 name="id"
> value="36090a01840ec6ccb8be664f48b00e04c">]
>
> children=[#<Nokogiri::XML::Text:0x4652bc0 "\n ">,
>
> #<Nokogiri::XML::Element:0x4652850 name="serial"
> children=[#<Nokogiri::XML::Text:0x4865afc
> "SEQLOGIC_100E-00_6090A01840EC6CCB8BE664F48B00E04C">]>,
>
> #<Nokogiri::XML::Text:0x486541c "\n ">,
>
> #<Nokogiri::XML::Element:0x4865278 name="vendor_id"
> children=[#<Nokogiri::XML::Text:0x4864f94 "EQLOGIC">]>,
>
> #<Nokogiri::XML::Text:0x4864b34 "\n ">,
>
> #<Nokogiri::XML::Element:0x48649b8 name="product_id"
> children=[#<Nokogiri::XML::Text:0x4864508 "100E-00">]>,
>
> #<Nokogiri::XML::Text:0x4504ea8 "\n ">,
>
> #<Nokogiri::XML::Element:0x4504c3c name="lun_mapping"
> children=[#<Nokogiri::XML::Text:0x4504340 "0">]>,
>
> #<Nokogiri::XML::Text:0x4503b5c "\n ">,
>
> #<Nokogiri::XML::Element:0x45038f0 name="size"
> children=[#<Nokogiri::XML::Text:0x468b8e4 "10737418240">]>,
>
> #<Nokogiri::XML::Text:0x468b380 "\n ">,
>
> #<Nokogiri::XML::Element:0x468b1dc name="paths"
> children=[#<Nokogiri::XML::Text:0x468adb8 "0">]>,
>
> #<Nokogiri::XML::Text:0x468a804 "\n ">,
>
> #<Nokogiri::XML::Element:0x468a46c name="disk_id"
> children=[#<Nokogiri::XML::Text:0x468a0fc
> "555af736-81d6-4334-a187-33122f3e445a">]>,
>
> #<Nokogiri::XML::Text:0x4689e18 "\n ">]>,
>
> #<Nokogiri::XML::Text:0x48b343c "\n ">]>,
>
> #<Nokogiri::XML::Text:0x48b2c30 "\n ">]>
>
>
>
can you confirm the fix at https://github.com/abenari/rbovirt/pull/37
solves the problem? does it have any side effects?

thanks,
Ohad

··· On Wed, Jun 25, 2014 at 11:27 PM, jvandewege wrote:

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

9

Well, it isn't in storage_domain.rb, its in volume.rb. The following
line has problems with iscsi direct luns.
@storage_domain = (xml/'storage_domains/storage_domain').first[:id]

Adding a rescue nil gets me a few lines further but it errors again, few
more rescue nils and voila I have a VM listing :slight_smile:
Attached the modified copy of volume.rb. Don't what this would break so
use at own risk and hopefully the devs can make this a little neater.

Added Bug #6399: No VM listing in the Compute Resource oVirt - Foreman

Joop

volume.rb (1.58 KB)

··· On 26-6-2014 8:55, jvandewege wrote: > On 26-6-2014 4:59, treydock wrote: >> I can confirm your findings. I too ran into the same issue with oVirt VMs using Direct LUNs via iSCSI and Foreman. At the time I was evaluating the performance benefit of Direct LUN vs VM images over iSCSI. In the end I chose images over Direct LUNs and forgot to file a bug report. I don't have any debug output as this was around the time of the oVirt 3.4 release, but thought I'd let you know your findings are correct. >> >> - Trey >> > Thanks Trey, I'll try to narrow it down today. I think the problem is in > the storagedomain.rb but need to inject some logger.debug statements to > make sure, I'll open a bug report on it. > > Joop >
10

I'll test the fix and let the list know.

Thanks for the fix btw :slight_smile:

Joop

··· On 30-6-2014 14:51, Ohad Levy wrote: > > > On Wed, Jun 25, 2014 at 11:27 PM, jvandewege > wrote: > > OK, probably found it. > > In Prod-oVirt we had VMs with disk which were direct luns, iscsi luns. > They are still in the system, either attached but inactive to VMs > or as > unattached disks. > Seems that some attribute from those disk is crashing rbovirt. > > > can you confirm the fix at https://github.com/abenari/rbovirt/pull/37 > solves the problem? does it have any side effects? > >
11

Fix will be available in 0.0.28

Joop

··· On 30-6-2014 15:05, jvandewege wrote: > On 30-6-2014 14:51, Ohad Levy wrote: >> >> >> On Wed, Jun 25, 2014 at 11:27 PM, jvandewege > > wrote: >> >> OK, probably found it. >> >> In Prod-oVirt we had VMs with disk which were direct luns, iscsi >> luns. >> They are still in the system, either attached but inactive to VMs >> or as >> unattached disks. >> Seems that some attribute from those disk is crashing rbovirt. >> >> >> can you confirm the fix at https://github.com/abenari/rbovirt/pull/37 >> solves the problem? does it have any side effects? >> >> > I'll test the fix and let the list know. > > Thanks for the fix btw :-)