[ovirt-users] Re: Latest ManagedBlockDevice documentation
On 10/15/20 11:27 AM, Jeff Bailey wrote: On 10/15/2020 12:07 PM, Michael Thomas wrote: On 10/15/20 10:19 AM, Jeff Bailey wrote: On 10/15/2020 10:01 AM, Michael Thomas wrote: Getting closer... I recreated the storage domain and added rbd_default_features=3 to ceph.conf. Now I see the new disk being created with (what I think is) the correct set of features: # rbd info rbd.ovirt.data/volume-f4ac68c6-e5f7-4b01-aed0-36a55b901 fbf rbd image 'volume-f4ac68c6-e5f7-4b01-aed0-36a55b901fbf': size 100 GiB in 25600 objects order 22 (4 MiB objects) snapshot_count: 0 id: 70aab541cb331 block_name_prefix: rbd_data.70aab541cb331 format: 2 features: layering op_features: flags: create_timestamp: Thu Oct 15 06:53:23 2020 access_timestamp: Thu Oct 15 06:53:23 2020 modify_timestamp: Thu Oct 15 06:53:23 2020 However, I'm still unable to attach the disk to a VM. This time it's a permissions issue on the ovirt node where the VM is running. It looks like it can't read the temporary ceph config file that is sent over from the engine: Are you using octopus? If so, the config file that's generated is missing the "[global]" at the top and octopus doesn't like that. It's been patched upstream. Yes, I am using Octopus (15.2.4). Do you have a pointer to the upstream patch or issue so that I can watch for a release with the fix? https://bugs.launchpad.net/cinder/+bug/1865754 And for anyone playing along at home, I was able to map this back to the openstack ticket: https://review.opendev.org/#/c/730376/ It's a simple fix. I just changed line 100 of /usr/lib/python3.6/site-packages/os_brick/initiator/connectors/rbd.py to: conf_file.writelines(["[global]", "\n", mon_hosts, "\n", keyring, "\n"]) After applying this patch, I was finally able to attach my ceph block device to a running VM. I've now got virtually unlimited data storage for my VMs. Many thanks to you and Benny for the help! --Mike ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/UET4Q7BDRBWPWSQ4FNZY5XW6S4LJV4KK/
[ovirt-users] Re: Latest ManagedBlockDevice documentation
On 10/15/2020 12:07 PM, Michael Thomas wrote: On 10/15/20 10:19 AM, Jeff Bailey wrote: On 10/15/2020 10:01 AM, Michael Thomas wrote: Getting closer... I recreated the storage domain and added rbd_default_features=3 to ceph.conf. Now I see the new disk being created with (what I think is) the correct set of features: # rbd info rbd.ovirt.data/volume-f4ac68c6-e5f7-4b01-aed0-36a55b901 fbf rbd image 'volume-f4ac68c6-e5f7-4b01-aed0-36a55b901fbf': size 100 GiB in 25600 objects order 22 (4 MiB objects) snapshot_count: 0 id: 70aab541cb331 block_name_prefix: rbd_data.70aab541cb331 format: 2 features: layering op_features: flags: create_timestamp: Thu Oct 15 06:53:23 2020 access_timestamp: Thu Oct 15 06:53:23 2020 modify_timestamp: Thu Oct 15 06:53:23 2020 However, I'm still unable to attach the disk to a VM. This time it's a permissions issue on the ovirt node where the VM is running. It looks like it can't read the temporary ceph config file that is sent over from the engine: Are you using octopus? If so, the config file that's generated is missing the "[global]" at the top and octopus doesn't like that. It's been patched upstream. Yes, I am using Octopus (15.2.4). Do you have a pointer to the upstream patch or issue so that I can watch for a release with the fix? https://bugs.launchpad.net/cinder/+bug/1865754 It's a simple fix. I just changed line 100 of /usr/lib/python3.6/site-packages/os_brick/initiator/connectors/rbd.py to: conf_file.writelines(["[global]", "\n", mon_hosts, "\n", keyring, "\n"]) --Mike ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/KUO5OQWJDAHC25YLYVATQ6U2LLT6PH5Z/
[ovirt-users] Re: Latest ManagedBlockDevice documentation
On 10/15/20 10:19 AM, Jeff Bailey wrote: On 10/15/2020 10:01 AM, Michael Thomas wrote: Getting closer... I recreated the storage domain and added rbd_default_features=3 to ceph.conf. Now I see the new disk being created with (what I think is) the correct set of features: # rbd info rbd.ovirt.data/volume-f4ac68c6-e5f7-4b01-aed0-36a55b901 fbf rbd image 'volume-f4ac68c6-e5f7-4b01-aed0-36a55b901fbf': size 100 GiB in 25600 objects order 22 (4 MiB objects) snapshot_count: 0 id: 70aab541cb331 block_name_prefix: rbd_data.70aab541cb331 format: 2 features: layering op_features: flags: create_timestamp: Thu Oct 15 06:53:23 2020 access_timestamp: Thu Oct 15 06:53:23 2020 modify_timestamp: Thu Oct 15 06:53:23 2020 However, I'm still unable to attach the disk to a VM. This time it's a permissions issue on the ovirt node where the VM is running. It looks like it can't read the temporary ceph config file that is sent over from the engine: Are you using octopus? If so, the config file that's generated is missing the "[global]" at the top and octopus doesn't like that. It's been patched upstream. Yes, I am using Octopus (15.2.4). Do you have a pointer to the upstream patch or issue so that I can watch for a release with the fix? --Mike ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/LBG4EEWFWDLSBTBLYD6NTBQWTBJRPQDK/
[ovirt-users] Re: Latest ManagedBlockDevice documentation
On 10/15/2020 10:01 AM, Michael Thomas wrote: Getting closer... I recreated the storage domain and added rbd_default_features=3 to ceph.conf. Now I see the new disk being created with (what I think is) the correct set of features: # rbd info rbd.ovirt.data/volume-f4ac68c6-e5f7-4b01-aed0-36a55b901 fbf rbd image 'volume-f4ac68c6-e5f7-4b01-aed0-36a55b901fbf': size 100 GiB in 25600 objects order 22 (4 MiB objects) snapshot_count: 0 id: 70aab541cb331 block_name_prefix: rbd_data.70aab541cb331 format: 2 features: layering op_features: flags: create_timestamp: Thu Oct 15 06:53:23 2020 access_timestamp: Thu Oct 15 06:53:23 2020 modify_timestamp: Thu Oct 15 06:53:23 2020 However, I'm still unable to attach the disk to a VM. This time it's a permissions issue on the ovirt node where the VM is running. It looks like it can't read the temporary ceph config file that is sent over from the engine: Are you using octopus? If so, the config file that's generated is missing the "[global]" at the top and octopus doesn't like that. It's been patched upstream. https://pastebin.com/pGjMTvcn The file '/tmp/brickrbd_nwc3kywk' on the ovirt node is only accessible by root: [root@ovirt4 ~]# ls -l /tmp/brickrbd_nwc3kywk -rw---. 1 root root 146 Oct 15 07:25 /tmp/brickrbd_nwc3kywk ...and I'm guessing that it's being accessed by the vdsm user? --Mike On 10/14/20 10:59 AM, Michael Thomas wrote: Hi Benny, You are correct, I tried attaching to a running VM (which failed), then tried booting a new VM using this disk (which also failed). I'll use the workaround in the bug report going forward. I'll just recreate the storage domain, since at this point I have nothing in it to lose. Regards, --Mike On 10/14/20 9:32 AM, Benny Zlotnik wrote: Did you attempt to start a VM with this disk and it failed, or you didn't try at all? If it's the latter then the error is strange... If it's the former there is a known issue with multipath at the moment, see[1] for a workaround, since you might have issues with detaching volumes which later, because multipath grabs the rbd devices which would fail `rbd unmap`, it will be fixed soon by automatically blacklisting rbd in multipath configuration. Regarding editing, you can submit an RFE for this, but it is currently not possible. The options are indeed to either recreate the storage domain or edit the database table [1] https://bugzilla.redhat.com/show_bug.cgi?id=1881832#c8 On Wed, Oct 14, 2020 at 3:40 PM Michael Thomas wrote: On 10/14/20 3:30 AM, Benny Zlotnik wrote: Jeff is right, it's a limitation of kernel rbd, the recommendation is to add `rbd default features = 3` to the configuration. I think there are plans to support rbd-nbd in cinderlib which would allow using additional features, but I'm not aware of anything concrete. Additionally, the path for the cinderlib log is /var/log/ovirt-engine/cinderlib/cinderlib.log, the error in this case would appear in the vdsm.log on the relevant host, and would look something like "RBD image feature set mismatch. You can disable features unsupported by the kernel with 'rbd feature disable'" Thanks for the pointer! Indeed, /var/log/ovirt-engine/cinderlib/cinderlib.log has the errors that I was looking for. In this case, it was a user error entering the RBDDriver options: 2020-10-13 15:15:25,640 - cinderlib.cinderlib - WARNING - Unknown config option use_multipath_for_xfer ...it should have been 'use_multipath_for_image_xfer'. Now my attempts to fix it are failing... If I go to 'Storage -> Storage Domains -> Manage Domain', all driver options are unedittable except for 'Name'. Then I thought that maybe I can't edit the driver options while a disk still exists, so I tried removing the one disk in this domain. But even after multiple attempts, it still fails with: 2020-10-14 07:26:31,340 - cinder.volume.drivers.rbd - INFO - volume volume-5419640e-445f-4b3f-a29d-b316ad031b7a no longer exists in backend 2020-10-14 07:26:31,353 - cinderlib-client - ERROR - Failure occurred when trying to run command 'delete_volume': (psycopg2.IntegrityError) update or delete on table "volumes" violates foreign key constraint "volume_attachment_volume_id_fkey" on table "volume_attachment" DETAIL: Key (id)=(5419640e-445f-4b3f-a29d-b316ad031b7a) is still referenced from table "volume_attachment". See https://pastebin.com/KwN1Vzsp for the full log entries related to this removal. It's not lying, the volume no longer exists in the rbd pool, but the cinder database still thinks it's attached, even though I was never able to get it to attach to a VM. What are my options for cleaning up this stale disk in the cinder database? How can I update the driver options in my storage domain (deleting and recreating the domain is acceptable, if possible)? --Mike ___ Users
[ovirt-users] Re: Latest ManagedBlockDevice documentation
Getting closer... I recreated the storage domain and added rbd_default_features=3 to ceph.conf. Now I see the new disk being created with (what I think is) the correct set of features: # rbd info rbd.ovirt.data/volume-f4ac68c6-e5f7-4b01-aed0-36a55b901 fbf rbd image 'volume-f4ac68c6-e5f7-4b01-aed0-36a55b901fbf': size 100 GiB in 25600 objects order 22 (4 MiB objects) snapshot_count: 0 id: 70aab541cb331 block_name_prefix: rbd_data.70aab541cb331 format: 2 features: layering op_features: flags: create_timestamp: Thu Oct 15 06:53:23 2020 access_timestamp: Thu Oct 15 06:53:23 2020 modify_timestamp: Thu Oct 15 06:53:23 2020 However, I'm still unable to attach the disk to a VM. This time it's a permissions issue on the ovirt node where the VM is running. It looks like it can't read the temporary ceph config file that is sent over from the engine: https://pastebin.com/pGjMTvcn The file '/tmp/brickrbd_nwc3kywk' on the ovirt node is only accessible by root: [root@ovirt4 ~]# ls -l /tmp/brickrbd_nwc3kywk -rw---. 1 root root 146 Oct 15 07:25 /tmp/brickrbd_nwc3kywk ...and I'm guessing that it's being accessed by the vdsm user? --Mike On 10/14/20 10:59 AM, Michael Thomas wrote: Hi Benny, You are correct, I tried attaching to a running VM (which failed), then tried booting a new VM using this disk (which also failed). I'll use the workaround in the bug report going forward. I'll just recreate the storage domain, since at this point I have nothing in it to lose. Regards, --Mike On 10/14/20 9:32 AM, Benny Zlotnik wrote: Did you attempt to start a VM with this disk and it failed, or you didn't try at all? If it's the latter then the error is strange... If it's the former there is a known issue with multipath at the moment, see[1] for a workaround, since you might have issues with detaching volumes which later, because multipath grabs the rbd devices which would fail `rbd unmap`, it will be fixed soon by automatically blacklisting rbd in multipath configuration. Regarding editing, you can submit an RFE for this, but it is currently not possible. The options are indeed to either recreate the storage domain or edit the database table [1] https://bugzilla.redhat.com/show_bug.cgi?id=1881832#c8 On Wed, Oct 14, 2020 at 3:40 PM Michael Thomas wrote: On 10/14/20 3:30 AM, Benny Zlotnik wrote: Jeff is right, it's a limitation of kernel rbd, the recommendation is to add `rbd default features = 3` to the configuration. I think there are plans to support rbd-nbd in cinderlib which would allow using additional features, but I'm not aware of anything concrete. Additionally, the path for the cinderlib log is /var/log/ovirt-engine/cinderlib/cinderlib.log, the error in this case would appear in the vdsm.log on the relevant host, and would look something like "RBD image feature set mismatch. You can disable features unsupported by the kernel with 'rbd feature disable'" Thanks for the pointer! Indeed, /var/log/ovirt-engine/cinderlib/cinderlib.log has the errors that I was looking for. In this case, it was a user error entering the RBDDriver options: 2020-10-13 15:15:25,640 - cinderlib.cinderlib - WARNING - Unknown config option use_multipath_for_xfer ...it should have been 'use_multipath_for_image_xfer'. Now my attempts to fix it are failing... If I go to 'Storage -> Storage Domains -> Manage Domain', all driver options are unedittable except for 'Name'. Then I thought that maybe I can't edit the driver options while a disk still exists, so I tried removing the one disk in this domain. But even after multiple attempts, it still fails with: 2020-10-14 07:26:31,340 - cinder.volume.drivers.rbd - INFO - volume volume-5419640e-445f-4b3f-a29d-b316ad031b7a no longer exists in backend 2020-10-14 07:26:31,353 - cinderlib-client - ERROR - Failure occurred when trying to run command 'delete_volume': (psycopg2.IntegrityError) update or delete on table "volumes" violates foreign key constraint "volume_attachment_volume_id_fkey" on table "volume_attachment" DETAIL: Key (id)=(5419640e-445f-4b3f-a29d-b316ad031b7a) is still referenced from table "volume_attachment". See https://pastebin.com/KwN1Vzsp for the full log entries related to this removal. It's not lying, the volume no longer exists in the rbd pool, but the cinder database still thinks it's attached, even though I was never able to get it to attach to a VM. What are my options for cleaning up this stale disk in the cinder database? How can I update the driver options in my storage domain (deleting and recreating the domain is acceptable, if possible)? --Mike ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List
[ovirt-users] Re: Latest ManagedBlockDevice documentation
Hi Benny, You are correct, I tried attaching to a running VM (which failed), then tried booting a new VM using this disk (which also failed). I'll use the workaround in the bug report going forward. I'll just recreate the storage domain, since at this point I have nothing in it to lose. Regards, --Mike On 10/14/20 9:32 AM, Benny Zlotnik wrote: > Did you attempt to start a VM with this disk and it failed, or you > didn't try at all? If it's the latter then the error is strange... > If it's the former there is a known issue with multipath at the > moment, see[1] for a workaround, since you might have issues with > detaching volumes which later, because multipath grabs the rbd devices > which would fail `rbd unmap`, it will be fixed soon by automatically > blacklisting rbd in multipath configuration. > > Regarding editing, you can submit an RFE for this, but it is currently > not possible. The options are indeed to either recreate the storage > domain or edit the database table > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1881832#c8 > > > > > On Wed, Oct 14, 2020 at 3:40 PM Michael Thomas wrote: >> >> On 10/14/20 3:30 AM, Benny Zlotnik wrote: >>> Jeff is right, it's a limitation of kernel rbd, the recommendation is >>> to add `rbd default features = 3` to the configuration. I think there >>> are plans to support rbd-nbd in cinderlib which would allow using >>> additional features, but I'm not aware of anything concrete. >>> >>> Additionally, the path for the cinderlib log is >>> /var/log/ovirt-engine/cinderlib/cinderlib.log, the error in this case >>> would appear in the vdsm.log on the relevant host, and would look >>> something like "RBD image feature set mismatch. You can disable >>> features unsupported by the kernel with 'rbd feature disable'" >> >> Thanks for the pointer! Indeed, >> /var/log/ovirt-engine/cinderlib/cinderlib.log has the errors that I was >> looking for. In this case, it was a user error entering the RBDDriver >> options: >> >> >> 2020-10-13 15:15:25,640 - cinderlib.cinderlib - WARNING - Unknown config >> option use_multipath_for_xfer >> >> ...it should have been 'use_multipath_for_image_xfer'. >> >> Now my attempts to fix it are failing... If I go to 'Storage -> Storage >> Domains -> Manage Domain', all driver options are unedittable except for >> 'Name'. >> >> Then I thought that maybe I can't edit the driver options while a disk >> still exists, so I tried removing the one disk in this domain. But even >> after multiple attempts, it still fails with: >> >> 2020-10-14 07:26:31,340 - cinder.volume.drivers.rbd - INFO - volume >> volume-5419640e-445f-4b3f-a29d-b316ad031b7a no longer exists in backend >> 2020-10-14 07:26:31,353 - cinderlib-client - ERROR - Failure occurred >> when trying to run command 'delete_volume': (psycopg2.IntegrityError) >> update or delete on table "volumes" violates foreign key constraint >> "volume_attachment_volume_id_fkey" on table "volume_attachment" >> DETAIL: Key (id)=(5419640e-445f-4b3f-a29d-b316ad031b7a) is still >> referenced from table "volume_attachment". >> >> See https://pastebin.com/KwN1Vzsp for the full log entries related to >> this removal. >> >> It's not lying, the volume no longer exists in the rbd pool, but the >> cinder database still thinks it's attached, even though I was never able >> to get it to attach to a VM. >> >> What are my options for cleaning up this stale disk in the cinder database? >> >> How can I update the driver options in my storage domain (deleting and >> recreating the domain is acceptable, if possible)? >> >> --Mike >> > ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/3WIVWLKS347QKA2GMIGF4ZEMLFBJQ7SU/
[ovirt-users] Re: Latest ManagedBlockDevice documentation
sorry, accidentally hit send prematurely, the database table is driver_options, the options are json under driver_options On Wed, Oct 14, 2020 at 5:32 PM Benny Zlotnik wrote: > > Did you attempt to start a VM with this disk and it failed, or you > didn't try at all? If it's the latter then the error is strange... > If it's the former there is a known issue with multipath at the > moment, see[1] for a workaround, since you might have issues with > detaching volumes which later, because multipath grabs the rbd devices > which would fail `rbd unmap`, it will be fixed soon by automatically > blacklisting rbd in multipath configuration. > > Regarding editing, you can submit an RFE for this, but it is currently > not possible. The options are indeed to either recreate the storage > domain or edit the database table > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1881832#c8 > > > > > On Wed, Oct 14, 2020 at 3:40 PM Michael Thomas wrote: > > > > On 10/14/20 3:30 AM, Benny Zlotnik wrote: > > > Jeff is right, it's a limitation of kernel rbd, the recommendation is > > > to add `rbd default features = 3` to the configuration. I think there > > > are plans to support rbd-nbd in cinderlib which would allow using > > > additional features, but I'm not aware of anything concrete. > > > > > > Additionally, the path for the cinderlib log is > > > /var/log/ovirt-engine/cinderlib/cinderlib.log, the error in this case > > > would appear in the vdsm.log on the relevant host, and would look > > > something like "RBD image feature set mismatch. You can disable > > > features unsupported by the kernel with 'rbd feature disable'" > > > > Thanks for the pointer! Indeed, > > /var/log/ovirt-engine/cinderlib/cinderlib.log has the errors that I was > > looking for. In this case, it was a user error entering the RBDDriver > > options: > > > > > > 2020-10-13 15:15:25,640 - cinderlib.cinderlib - WARNING - Unknown config > > option use_multipath_for_xfer > > > > ...it should have been 'use_multipath_for_image_xfer'. > > > > Now my attempts to fix it are failing... If I go to 'Storage -> Storage > > Domains -> Manage Domain', all driver options are unedittable except for > > 'Name'. > > > > Then I thought that maybe I can't edit the driver options while a disk > > still exists, so I tried removing the one disk in this domain. But even > > after multiple attempts, it still fails with: > > > > 2020-10-14 07:26:31,340 - cinder.volume.drivers.rbd - INFO - volume > > volume-5419640e-445f-4b3f-a29d-b316ad031b7a no longer exists in backend > > 2020-10-14 07:26:31,353 - cinderlib-client - ERROR - Failure occurred > > when trying to run command 'delete_volume': (psycopg2.IntegrityError) > > update or delete on table "volumes" violates foreign key constraint > > "volume_attachment_volume_id_fkey" on table "volume_attachment" > > DETAIL: Key (id)=(5419640e-445f-4b3f-a29d-b316ad031b7a) is still > > referenced from table "volume_attachment". > > > > See https://pastebin.com/KwN1Vzsp for the full log entries related to > > this removal. > > > > It's not lying, the volume no longer exists in the rbd pool, but the > > cinder database still thinks it's attached, even though I was never able > > to get it to attach to a VM. > > > > What are my options for cleaning up this stale disk in the cinder database? > > > > How can I update the driver options in my storage domain (deleting and > > recreating the domain is acceptable, if possible)? > > > > --Mike > > ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/BQPXZYCE5GWKSHDN5FU7I5L4VP75QPEJ/
[ovirt-users] Re: Latest ManagedBlockDevice documentation
Did you attempt to start a VM with this disk and it failed, or you didn't try at all? If it's the latter then the error is strange... If it's the former there is a known issue with multipath at the moment, see[1] for a workaround, since you might have issues with detaching volumes which later, because multipath grabs the rbd devices which would fail `rbd unmap`, it will be fixed soon by automatically blacklisting rbd in multipath configuration. Regarding editing, you can submit an RFE for this, but it is currently not possible. The options are indeed to either recreate the storage domain or edit the database table [1] https://bugzilla.redhat.com/show_bug.cgi?id=1881832#c8 On Wed, Oct 14, 2020 at 3:40 PM Michael Thomas wrote: > > On 10/14/20 3:30 AM, Benny Zlotnik wrote: > > Jeff is right, it's a limitation of kernel rbd, the recommendation is > > to add `rbd default features = 3` to the configuration. I think there > > are plans to support rbd-nbd in cinderlib which would allow using > > additional features, but I'm not aware of anything concrete. > > > > Additionally, the path for the cinderlib log is > > /var/log/ovirt-engine/cinderlib/cinderlib.log, the error in this case > > would appear in the vdsm.log on the relevant host, and would look > > something like "RBD image feature set mismatch. You can disable > > features unsupported by the kernel with 'rbd feature disable'" > > Thanks for the pointer! Indeed, > /var/log/ovirt-engine/cinderlib/cinderlib.log has the errors that I was > looking for. In this case, it was a user error entering the RBDDriver > options: > > > 2020-10-13 15:15:25,640 - cinderlib.cinderlib - WARNING - Unknown config > option use_multipath_for_xfer > > ...it should have been 'use_multipath_for_image_xfer'. > > Now my attempts to fix it are failing... If I go to 'Storage -> Storage > Domains -> Manage Domain', all driver options are unedittable except for > 'Name'. > > Then I thought that maybe I can't edit the driver options while a disk > still exists, so I tried removing the one disk in this domain. But even > after multiple attempts, it still fails with: > > 2020-10-14 07:26:31,340 - cinder.volume.drivers.rbd - INFO - volume > volume-5419640e-445f-4b3f-a29d-b316ad031b7a no longer exists in backend > 2020-10-14 07:26:31,353 - cinderlib-client - ERROR - Failure occurred > when trying to run command 'delete_volume': (psycopg2.IntegrityError) > update or delete on table "volumes" violates foreign key constraint > "volume_attachment_volume_id_fkey" on table "volume_attachment" > DETAIL: Key (id)=(5419640e-445f-4b3f-a29d-b316ad031b7a) is still > referenced from table "volume_attachment". > > See https://pastebin.com/KwN1Vzsp for the full log entries related to > this removal. > > It's not lying, the volume no longer exists in the rbd pool, but the > cinder database still thinks it's attached, even though I was never able > to get it to attach to a VM. > > What are my options for cleaning up this stale disk in the cinder database? > > How can I update the driver options in my storage domain (deleting and > recreating the domain is acceptable, if possible)? > > --Mike > ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/Q5IC4SDS5AS64RIOKHBFNQDWCOBKKDJW/
[ovirt-users] Re: Latest ManagedBlockDevice documentation
On 10/14/20 3:30 AM, Benny Zlotnik wrote: Jeff is right, it's a limitation of kernel rbd, the recommendation is to add `rbd default features = 3` to the configuration. I think there are plans to support rbd-nbd in cinderlib which would allow using additional features, but I'm not aware of anything concrete. Additionally, the path for the cinderlib log is /var/log/ovirt-engine/cinderlib/cinderlib.log, the error in this case would appear in the vdsm.log on the relevant host, and would look something like "RBD image feature set mismatch. You can disable features unsupported by the kernel with 'rbd feature disable'" Thanks for the pointer! Indeed, /var/log/ovirt-engine/cinderlib/cinderlib.log has the errors that I was looking for. In this case, it was a user error entering the RBDDriver options: 2020-10-13 15:15:25,640 - cinderlib.cinderlib - WARNING - Unknown config option use_multipath_for_xfer ...it should have been 'use_multipath_for_image_xfer'. Now my attempts to fix it are failing... If I go to 'Storage -> Storage Domains -> Manage Domain', all driver options are unedittable except for 'Name'. Then I thought that maybe I can't edit the driver options while a disk still exists, so I tried removing the one disk in this domain. But even after multiple attempts, it still fails with: 2020-10-14 07:26:31,340 - cinder.volume.drivers.rbd - INFO - volume volume-5419640e-445f-4b3f-a29d-b316ad031b7a no longer exists in backend 2020-10-14 07:26:31,353 - cinderlib-client - ERROR - Failure occurred when trying to run command 'delete_volume': (psycopg2.IntegrityError) update or delete on table "volumes" violates foreign key constraint "volume_attachment_volume_id_fkey" on table "volume_attachment" DETAIL: Key (id)=(5419640e-445f-4b3f-a29d-b316ad031b7a) is still referenced from table "volume_attachment". See https://pastebin.com/KwN1Vzsp for the full log entries related to this removal. It's not lying, the volume no longer exists in the rbd pool, but the cinder database still thinks it's attached, even though I was never able to get it to attach to a VM. What are my options for cleaning up this stale disk in the cinder database? How can I update the driver options in my storage domain (deleting and recreating the domain is acceptable, if possible)? --Mike ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/XTULDZ4DON6E4KMXQ5NVZQIZTRK4CZPQ/
[ovirt-users] Re: Latest ManagedBlockDevice documentation
Jeff is right, it's a limitation of kernel rbd, the recommendation is
to add `rbd default features = 3` to the configuration. I think there
are plans to support rbd-nbd in cinderlib which would allow using
additional features, but I'm not aware of anything concrete.
Additionally, the path for the cinderlib log is
/var/log/ovirt-engine/cinderlib/cinderlib.log, the error in this case
would appear in the vdsm.log on the relevant host, and would look
something like "RBD image feature set mismatch. You can disable
features unsupported by the kernel with 'rbd feature disable'"
On Wed, Oct 14, 2020 at 12:01 AM Michael Thomas wrote:
>
> After getting past the proxy issue, I was finally able to run the
> engine-setup --reconfigure-optional-components. The new
> ManagedBlockStorage storage domain exists, and I was able to create a
> disk. However, I am unable to attach the disk to a running VM.
>
> The engine.log shows the following, with a reference to a possible
> cinderlib error ("cinderlib execution failed"):
>
> 2020-10-13 15:15:23,508-05 INFO
> [org.ovirt.engine.core.bll.UpdateVmCommand] (default task-13)
> [c73386d0-a713-4c37-bc9b-e7c4f9083f78] Lock Acquired to object
> 'EngineLock:{exclusiveLocks='[grafana=VM_NAME]',
> sharedLocks='[5676d441-660e-4d9f-a586-e53ff0ea054b=VM]'}'
> 2020-10-13 15:15:23,522-05 INFO
> [org.ovirt.engine.core.bll.UpdateVmCommand] (default task-13)
> [c73386d0-a713-4c37-bc9b-e7c4f9083f78] Running command: UpdateVmCommand
> internal: false. Entities affected : ID:
> 5676d441-660e-4d9f-a586-e53ff0ea054b Type: VMAction group
> EDIT_VM_PROPERTIES with role type USER
> 2020-10-13 15:15:23,536-05 INFO
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-13) [c73386d0-a713-4c37-bc9b-e7c4f9083f78] EVENT_ID:
> USER_UPDATE_VM(35), VM grafana configuration was updated by
> michael.thomas@internal-authz.
> 2020-10-13 15:15:23,539-05 INFO
> [org.ovirt.engine.core.bll.UpdateVmCommand] (default task-13)
> [c73386d0-a713-4c37-bc9b-e7c4f9083f78] Lock freed to object
> 'EngineLock:{exclusiveLocks='[grafana=VM_NAME]',
> sharedLocks='[5676d441-660e-4d9f-a586-e53ff0ea054b=VM]'}'
> 2020-10-13 15:15:24,129-05 INFO
> [org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand] (default
> task-13) [f8829338-b040-46d0-a838-3cf28869637c] Lock Acquired to object
> 'EngineLock:{exclusiveLocks='[5419640e-445f-4b3f-a29d-b316ad031b7a=DISK]',
> sharedLocks=''}'
> 2020-10-13 15:15:24,147-05 INFO
> [org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand] (default
> task-13) [f8829338-b040-46d0-a838-3cf28869637c] Running command:
> AttachDiskToVmCommand internal: false. Entities affected : ID:
> 5676d441-660e-4d9f-a586-e53ff0ea054b Type: VMAction group
> CONFIGURE_VM_STORAGE with role type USER, ID:
> 5419640e-445f-4b3f-a29d-b316ad031b7a Type: DiskAction group ATTACH_DISK
> with role type USER
> 2020-10-13 15:15:24,152-05 INFO
> [org.ovirt.engine.core.bll.storage.disk.managedblock.ConnectManagedBlockStorageDeviceCommand]
> (default task-13) [7cb262cc] Running command:
> ConnectManagedBlockStorageDeviceCommand internal: true.
> 2020-10-13 15:15:26,006-05 ERROR
> [org.ovirt.engine.core.common.utils.cinderlib.CinderlibExecutor]
> (default task-13) [7cb262cc] cinderlib execution failed:
> 2020-10-13 15:15:26,011-05 INFO
> [org.ovirt.engine.core.vdsbroker.vdsbroker.HotPlugDiskVDSCommand]
> (default task-13) [7cb262cc] START, HotPlugDiskVDSCommand(HostName =
> ovirt4-mgmt.ldas.ligo-la.caltech.edu,
> HotPlugDiskVDSParameters:{hostId='61da4cdf-638b-4cbd-9921-5be820998d31',
> vmId='5676d441-660e-4d9f-a586-e53ff0ea054b',
> diskId='5419640e-445f-4b3f-a29d-b316ad031b7a'}), log id: 660ebc9e
> 2020-10-13 15:15:26,012-05 ERROR
> [org.ovirt.engine.core.vdsbroker.vdsbroker.HotPlugDiskVDSCommand]
> (default task-13) [7cb262cc] Failed in 'HotPlugDiskVDS' method, for vds:
> 'ovirt4-mgmt.ldas.ligo-la.caltech.edu'; host:
> 'ovirt4-mgmt.ldas.ligo-la.caltech.edu': null
> 2020-10-13 15:15:26,012-05 ERROR
> [org.ovirt.engine.core.vdsbroker.vdsbroker.HotPlugDiskVDSCommand]
> (default task-13) [7cb262cc] Command 'HotPlugDiskVDSCommand(HostName =
> ovirt4-mgmt.ldas.ligo-la.caltech.edu,
> HotPlugDiskVDSParameters:{hostId='61da4cdf-638b-4cbd-9921-5be820998d31',
> vmId='5676d441-660e-4d9f-a586-e53ff0ea054b',
> diskId='5419640e-445f-4b3f-a29d-b316ad031b7a'})' execution failed: null
> 2020-10-13 15:15:26,012-05 INFO
> [org.ovirt.engine.core.vdsbroker.vdsbroker.HotPlugDiskVDSCommand]
> (default task-13) [7cb262cc] FINISH, HotPlugDiskVDSCommand, return: ,
> log id: 660ebc9e
> 2020-10-13 15:15:26,012-05 ERROR
> [org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand] (default
> task-13) [7cb262cc] Command
> 'org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand' failed:
> EngineException: java.lang.NullPointerException (Failed with error
> ENGINE and code 5001)
> 2020-10-13 15:15:26,013-05 ERROR
> [org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand] (default
> task-13) [7cb262cc]
[ovirt-users] Re: Latest ManagedBlockDevice documentation
On 10/13/2020 5:01 PM, Michael Thomas wrote:
After getting past the proxy issue, I was finally able to run the
engine-setup --reconfigure-optional-components. The new
ManagedBlockStorage storage domain exists, and I was able to create a
disk. However, I am unable to attach the disk to a running VM.
The engine.log shows the following, with a reference to a possible
cinderlib error ("cinderlib execution failed"):
2020-10-13 15:15:23,508-05 INFO
[org.ovirt.engine.core.bll.UpdateVmCommand] (default task-13)
[c73386d0-a713-4c37-bc9b-e7c4f9083f78] Lock Acquired to object
'EngineLock:{exclusiveLocks='[grafana=VM_NAME]',
sharedLocks='[5676d441-660e-4d9f-a586-e53ff0ea054b=VM]'}'
2020-10-13 15:15:23,522-05 INFO
[org.ovirt.engine.core.bll.UpdateVmCommand] (default task-13)
[c73386d0-a713-4c37-bc9b-e7c4f9083f78] Running command:
UpdateVmCommand internal: false. Entities affected : ID:
5676d441-660e-4d9f-a586-e53ff0ea054b Type: VMAction group
EDIT_VM_PROPERTIES with role type USER
2020-10-13 15:15:23,536-05 INFO
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-13) [c73386d0-a713-4c37-bc9b-e7c4f9083f78] EVENT_ID:
USER_UPDATE_VM(35), VM grafana configuration was updated by
michael.thomas@internal-authz.
2020-10-13 15:15:23,539-05 INFO
[org.ovirt.engine.core.bll.UpdateVmCommand] (default task-13)
[c73386d0-a713-4c37-bc9b-e7c4f9083f78] Lock freed to object
'EngineLock:{exclusiveLocks='[grafana=VM_NAME]',
sharedLocks='[5676d441-660e-4d9f-a586-e53ff0ea054b=VM]'}'
2020-10-13 15:15:24,129-05 INFO
[org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand]
(default task-13) [f8829338-b040-46d0-a838-3cf28869637c] Lock Acquired
to object
'EngineLock:{exclusiveLocks='[5419640e-445f-4b3f-a29d-b316ad031b7a=DISK]',
sharedLocks=''}'
2020-10-13 15:15:24,147-05 INFO
[org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand]
(default task-13) [f8829338-b040-46d0-a838-3cf28869637c] Running
command: AttachDiskToVmCommand internal: false. Entities affected :
ID: 5676d441-660e-4d9f-a586-e53ff0ea054b Type: VMAction group
CONFIGURE_VM_STORAGE with role type USER, ID:
5419640e-445f-4b3f-a29d-b316ad031b7a Type: DiskAction group
ATTACH_DISK with role type USER
2020-10-13 15:15:24,152-05 INFO
[org.ovirt.engine.core.bll.storage.disk.managedblock.ConnectManagedBlockStorageDeviceCommand]
(default task-13) [7cb262cc] Running command:
ConnectManagedBlockStorageDeviceCommand internal: true.
2020-10-13 15:15:26,006-05 ERROR
[org.ovirt.engine.core.common.utils.cinderlib.CinderlibExecutor]
(default task-13) [7cb262cc] cinderlib execution failed:
2020-10-13 15:15:26,011-05 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.HotPlugDiskVDSCommand]
(default task-13) [7cb262cc] START, HotPlugDiskVDSCommand(HostName =
ovirt4-mgmt.ldas.ligo-la.caltech.edu,
HotPlugDiskVDSParameters:{hostId='61da4cdf-638b-4cbd-9921-5be820998d31',
vmId='5676d441-660e-4d9f-a586-e53ff0ea054b',
diskId='5419640e-445f-4b3f-a29d-b316ad031b7a'}), log id: 660ebc9e
2020-10-13 15:15:26,012-05 ERROR
[org.ovirt.engine.core.vdsbroker.vdsbroker.HotPlugDiskVDSCommand]
(default task-13) [7cb262cc] Failed in 'HotPlugDiskVDS' method, for
vds: 'ovirt4-mgmt.ldas.ligo-la.caltech.edu'; host:
'ovirt4-mgmt.ldas.ligo-la.caltech.edu': null
2020-10-13 15:15:26,012-05 ERROR
[org.ovirt.engine.core.vdsbroker.vdsbroker.HotPlugDiskVDSCommand]
(default task-13) [7cb262cc] Command 'HotPlugDiskVDSCommand(HostName =
ovirt4-mgmt.ldas.ligo-la.caltech.edu,
HotPlugDiskVDSParameters:{hostId='61da4cdf-638b-4cbd-9921-5be820998d31',
vmId='5676d441-660e-4d9f-a586-e53ff0ea054b',
diskId='5419640e-445f-4b3f-a29d-b316ad031b7a'})' execution failed: null
2020-10-13 15:15:26,012-05 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.HotPlugDiskVDSCommand]
(default task-13) [7cb262cc] FINISH, HotPlugDiskVDSCommand, return: ,
log id: 660ebc9e
2020-10-13 15:15:26,012-05 ERROR
[org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand]
(default task-13) [7cb262cc] Command
'org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand' failed:
EngineException: java.lang.NullPointerException (Failed with error
ENGINE and code 5001)
2020-10-13 15:15:26,013-05 ERROR
[org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand]
(default task-13) [7cb262cc] Transaction rolled-back for command
'org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand'.
2020-10-13 15:15:26,021-05 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-13) [7cb262cc] EVENT_ID:
USER_FAILED_ATTACH_DISK_TO_VM(2,017), Failed to attach Disk
testvm_disk to VM grafana (User: michael.thomas@internal-authz).
2020-10-13 15:15:26,021-05 INFO
[org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand]
(default task-13) [7cb262cc] Lock freed to object
'EngineLock:{exclusiveLocks='[5419640e-445f-4b3f-a29d-b316ad031b7a=DISK]',
sharedLocks=''}'
The /var/log/cinder/ directory on the ovirt node is empty, and doesn't
[ovirt-users] Re: Latest ManagedBlockDevice documentation
After getting past the proxy issue, I was finally able to run the
engine-setup --reconfigure-optional-components. The new
ManagedBlockStorage storage domain exists, and I was able to create a
disk. However, I am unable to attach the disk to a running VM.
The engine.log shows the following, with a reference to a possible
cinderlib error ("cinderlib execution failed"):
2020-10-13 15:15:23,508-05 INFO
[org.ovirt.engine.core.bll.UpdateVmCommand] (default task-13)
[c73386d0-a713-4c37-bc9b-e7c4f9083f78] Lock Acquired to object
'EngineLock:{exclusiveLocks='[grafana=VM_NAME]',
sharedLocks='[5676d441-660e-4d9f-a586-e53ff0ea054b=VM]'}'
2020-10-13 15:15:23,522-05 INFO
[org.ovirt.engine.core.bll.UpdateVmCommand] (default task-13)
[c73386d0-a713-4c37-bc9b-e7c4f9083f78] Running command: UpdateVmCommand
internal: false. Entities affected : ID:
5676d441-660e-4d9f-a586-e53ff0ea054b Type: VMAction group
EDIT_VM_PROPERTIES with role type USER
2020-10-13 15:15:23,536-05 INFO
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-13) [c73386d0-a713-4c37-bc9b-e7c4f9083f78] EVENT_ID:
USER_UPDATE_VM(35), VM grafana configuration was updated by
michael.thomas@internal-authz.
2020-10-13 15:15:23,539-05 INFO
[org.ovirt.engine.core.bll.UpdateVmCommand] (default task-13)
[c73386d0-a713-4c37-bc9b-e7c4f9083f78] Lock freed to object
'EngineLock:{exclusiveLocks='[grafana=VM_NAME]',
sharedLocks='[5676d441-660e-4d9f-a586-e53ff0ea054b=VM]'}'
2020-10-13 15:15:24,129-05 INFO
[org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand] (default
task-13) [f8829338-b040-46d0-a838-3cf28869637c] Lock Acquired to object
'EngineLock:{exclusiveLocks='[5419640e-445f-4b3f-a29d-b316ad031b7a=DISK]',
sharedLocks=''}'
2020-10-13 15:15:24,147-05 INFO
[org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand] (default
task-13) [f8829338-b040-46d0-a838-3cf28869637c] Running command:
AttachDiskToVmCommand internal: false. Entities affected : ID:
5676d441-660e-4d9f-a586-e53ff0ea054b Type: VMAction group
CONFIGURE_VM_STORAGE with role type USER, ID:
5419640e-445f-4b3f-a29d-b316ad031b7a Type: DiskAction group ATTACH_DISK
with role type USER
2020-10-13 15:15:24,152-05 INFO
[org.ovirt.engine.core.bll.storage.disk.managedblock.ConnectManagedBlockStorageDeviceCommand]
(default task-13) [7cb262cc] Running command:
ConnectManagedBlockStorageDeviceCommand internal: true.
2020-10-13 15:15:26,006-05 ERROR
[org.ovirt.engine.core.common.utils.cinderlib.CinderlibExecutor]
(default task-13) [7cb262cc] cinderlib execution failed:
2020-10-13 15:15:26,011-05 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.HotPlugDiskVDSCommand]
(default task-13) [7cb262cc] START, HotPlugDiskVDSCommand(HostName =
ovirt4-mgmt.ldas.ligo-la.caltech.edu,
HotPlugDiskVDSParameters:{hostId='61da4cdf-638b-4cbd-9921-5be820998d31',
vmId='5676d441-660e-4d9f-a586-e53ff0ea054b',
diskId='5419640e-445f-4b3f-a29d-b316ad031b7a'}), log id: 660ebc9e
2020-10-13 15:15:26,012-05 ERROR
[org.ovirt.engine.core.vdsbroker.vdsbroker.HotPlugDiskVDSCommand]
(default task-13) [7cb262cc] Failed in 'HotPlugDiskVDS' method, for vds:
'ovirt4-mgmt.ldas.ligo-la.caltech.edu'; host:
'ovirt4-mgmt.ldas.ligo-la.caltech.edu': null
2020-10-13 15:15:26,012-05 ERROR
[org.ovirt.engine.core.vdsbroker.vdsbroker.HotPlugDiskVDSCommand]
(default task-13) [7cb262cc] Command 'HotPlugDiskVDSCommand(HostName =
ovirt4-mgmt.ldas.ligo-la.caltech.edu,
HotPlugDiskVDSParameters:{hostId='61da4cdf-638b-4cbd-9921-5be820998d31',
vmId='5676d441-660e-4d9f-a586-e53ff0ea054b',
diskId='5419640e-445f-4b3f-a29d-b316ad031b7a'})' execution failed: null
2020-10-13 15:15:26,012-05 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.HotPlugDiskVDSCommand]
(default task-13) [7cb262cc] FINISH, HotPlugDiskVDSCommand, return: ,
log id: 660ebc9e
2020-10-13 15:15:26,012-05 ERROR
[org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand] (default
task-13) [7cb262cc] Command
'org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand' failed:
EngineException: java.lang.NullPointerException (Failed with error
ENGINE and code 5001)
2020-10-13 15:15:26,013-05 ERROR
[org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand] (default
task-13) [7cb262cc] Transaction rolled-back for command
'org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand'.
2020-10-13 15:15:26,021-05 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-13) [7cb262cc] EVENT_ID:
USER_FAILED_ATTACH_DISK_TO_VM(2,017), Failed to attach Disk testvm_disk
to VM grafana (User: michael.thomas@internal-authz).
2020-10-13 15:15:26,021-05 INFO
[org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand] (default
task-13) [7cb262cc] Lock freed to object
'EngineLock:{exclusiveLocks='[5419640e-445f-4b3f-a29d-b316ad031b7a=DISK]',
sharedLocks=''}'
The /var/log/cinder/ directory on the ovirt node is empty, and doesn't
exist on the engine itself.
To verify that
[ovirt-users] Re: Latest ManagedBlockDevice documentation
Setting both http_proxy and https_proxy fixed the issue. Thanks for the tip! --Mike I am not sure, it's been a long time since I tried that. Feel free to file a bug. You can also try setting env var 'http_proxy' for engine-setup, e.g.: http_proxy=MY_PROXY_URL engine-setup --reconfigure-optional-components Alternatively, you can also add '--offline' to engine-setup cmd, and then it won't do any package management (not try to update, check for updates, etc.). Best regards, [1] https://bugzilla.redhat.com/show_bug.cgi?id=1392312 --Mike On 9/30/20 2:19 AM, Benny Zlotnik wrote: When you ran `engine-setup` did you enable cinderlib preview (it will not be enabled by default)? It should handle the creation of the database automatically, if you didn't you can enable it by running: `engine-setup --reconfigure-optional-components` On Wed, Sep 30, 2020 at 1:58 AM Michael Thomas wrote: Hi Benny, Thanks for the confirmation. I've installed openstack-ussuri and ceph Octopus. Then I tried using these instructions, as well as the deep dive that Eyal has posted at https://www.youtube.com/watch?v=F3JttBkjsX8. I've done this a couple of times, and each time the engine fails when I try to add the new managed block storage domain. The error on the screen indicates that it can't connect to the cinder database. The error in the engine log is: 2020-09-29 17:02:11,859-05 WARN [org.ovirt.engine.core.bll.storage.domain.AddManagedBlockStorageDomainCommand] (default task-2) [d519088c-7956-4078-b5cf-156e5b3f1e59] Validation of action 'AddManagedBlockStorageDomain' failed for user admin@internal-authz. Reasons: VAR__TYPE__STORAGE__DOMAIN,VAR__ACTION__ADD,ACTION_TYPE_FAILED_CINDERLIB_DATA_BASE_REQUIRED,ACTION_TYPE_FAILED_CINDERLIB_DATA_BASE_REQUIRED I had created the db on the engine with this command: su - postgres -c "psql -d template1 -c \"create database cinder owner engine template template0 encoding 'UTF8' lc_collate 'en_US.UTF-8' lc_ctype 'en_US.UTF-8';\"" ...and added the following to the end of /var/lib/pgsql/data/pg_hba.conf: hostcinder engine ::0/0 md5 hostcinder engine 0.0.0.0/0 md5 Is there anywhere else I should look to find out what may have gone wrong? --Mike On 9/29/20 3:34 PM, Benny Zlotnik wrote: The feature is currently in tech preview, but it's being worked on. The feature page is outdated, but I believe this is what most users in the mailing list were using. We held off on updating it because the installation instructions have been a moving target, but it is more stable now and I will update it soon. Specifically speaking, the openstack version should be updated to train (it is likely ussuri works fine too, but I haven't tried it) and cinderlib has an RPM now (python3-cinderlib)[1], so it can be installed instead of using pip, same goes for os-brick. The rest of the information is valid. [1] http://mirror.centos.org/centos/8/cloud/x86_64/openstack-ussuri/Packages/p/ On Tue, Sep 29, 2020 at 10:37 PM Michael Thomas wrote: I'm looking for the latest documentation for setting up a Managed Block Device storage domain so that I can move some of my VM images to ceph rbd. I found this: https://ovirt.org/develop/release-management/features/storage/cinderlib-integration.html ...but it has a big note at the top that it is "...not user documentation and should not be treated as such." The oVirt administration guide[1] does not talk about managed block devices. I've found a few mailing list threads that discuss people setting up a Managed Block Device with ceph, but didn't see any links to documentation steps that folks were following. Is the Managed Block Storage domain a supported feature in oVirt 4.4.2, and if so, where is the documentation for using it? --Mike [1]ovirt.org/documentation/administration_guide/ ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/KHCLXVOCELHOR3G7SH3GDPGRKITCW7UY/ ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/2KT3QQZZESXOTSQFBZZXYDH5WNZVKMJZ/
[ovirt-users] Re: Latest ManagedBlockDevice documentation
On Wed, Sep 30, 2020 at 4:43 PM Benny Zlotnik wrote: > > Not sure about this, adding +Yedidyah Bar David > > On Wed, Sep 30, 2020 at 3:04 PM Michael Thomas wrote: > > > > I hadn't installed the necessary packages when the engine was first > > installed. > > > > However, running 'engine-setup --reconfigure-optional-components' > > doesn't work at the moment because (by design) my engine does not have a > > network route outside of the cluster. It fails with: > > > > [ INFO ] DNF Errors during downloading metadata for repository 'AppStream': > > - Curl error (7): Couldn't connect to server for > > http://mirrorlist.centos.org/?release=8=x86_64=AppStream=$infra > > [Failed to connect to mirrorlist.centos.org port 80: Network is unreachable] > > [ ERROR ] DNF Failed to download metadata for repo 'AppStream': Cannot > > prepare internal mirrorlist: Curl error (7): Couldn't connect to server > > for > > http://mirrorlist.centos.org/?release=8=x86_64=AppStream=$infra > > [Failed to connect to mirrorlist.centos.org port 80: Network is unreachable] > > > > > > I have a proxy set in the engine's /etc/dnf/dnf.conf, but it doesn't > > seem to be obeyed when running engine-setup. Is there another way that > > I can get engine-setup to use a proxy? I am not sure, it's been a long time since I tried that. Feel free to file a bug. You can also try setting env var 'http_proxy' for engine-setup, e.g.: http_proxy=MY_PROXY_URL engine-setup --reconfigure-optional-components Alternatively, you can also add '--offline' to engine-setup cmd, and then it won't do any package management (not try to update, check for updates, etc.). Best regards, [1] https://bugzilla.redhat.com/show_bug.cgi?id=1392312 > > > > --Mike > > > > > > On 9/30/20 2:19 AM, Benny Zlotnik wrote: > > > When you ran `engine-setup` did you enable cinderlib preview (it will > > > not be enabled by default)? > > > It should handle the creation of the database automatically, if you > > > didn't you can enable it by running: > > > `engine-setup --reconfigure-optional-components` > > > > > > > > > On Wed, Sep 30, 2020 at 1:58 AM Michael Thomas wrote: > > >> > > >> Hi Benny, > > >> > > >> Thanks for the confirmation. I've installed openstack-ussuri and ceph > > >> Octopus. Then I tried using these instructions, as well as the deep > > >> dive that Eyal has posted at https://www.youtube.com/watch?v=F3JttBkjsX8. > > >> > > >> I've done this a couple of times, and each time the engine fails when I > > >> try to add the new managed block storage domain. The error on the > > >> screen indicates that it can't connect to the cinder database. The > > >> error in the engine log is: > > >> > > >> 2020-09-29 17:02:11,859-05 WARN > > >> [org.ovirt.engine.core.bll.storage.domain.AddManagedBlockStorageDomainCommand] > > >> (default task-2) [d519088c-7956-4078-b5cf-156e5b3f1e59] Validation of > > >> action 'AddManagedBlockStorageDomain' failed for user > > >> admin@internal-authz. Reasons: > > >> VAR__TYPE__STORAGE__DOMAIN,VAR__ACTION__ADD,ACTION_TYPE_FAILED_CINDERLIB_DATA_BASE_REQUIRED,ACTION_TYPE_FAILED_CINDERLIB_DATA_BASE_REQUIRED > > >> > > >> I had created the db on the engine with this command: > > >> > > >> su - postgres -c "psql -d template1 -c \"create database cinder owner > > >> engine template template0 encoding 'UTF8' lc_collate 'en_US.UTF-8' > > >> lc_ctype 'en_US.UTF-8';\"" > > >> > > >> ...and added the following to the end of /var/lib/pgsql/data/pg_hba.conf: > > >> > > >> hostcinder engine ::0/0 md5 > > >> hostcinder engine 0.0.0.0/0 md5 > > >> > > >> Is there anywhere else I should look to find out what may have gone > > >> wrong? > > >> > > >> --Mike > > >> > > >> On 9/29/20 3:34 PM, Benny Zlotnik wrote: > > >>> The feature is currently in tech preview, but it's being worked on. > > >>> The feature page is outdated, but I believe this is what most users > > >>> in the mailing list were using. We held off on updating it because the > > >>> installation instructions have been a moving target, but it is more > > >>> stable now and I will update it soon. > > >>> > > >>> Specifically speaking, the openstack version should be updated to > > >>> train (it is likely ussuri works fine too, but I haven't tried it) and > > >>> cinderlib has an RPM now (python3-cinderlib)[1], so it can be > > >>> installed instead of using pip, same goes for os-brick. The rest of > > >>> the information is valid. > > >>> > > >>> > > >>> [1] > > >>> http://mirror.centos.org/centos/8/cloud/x86_64/openstack-ussuri/Packages/p/ > > >>> > > >>> On Tue, Sep 29, 2020 at 10:37 PM Michael Thomas > > >>> wrote: > > > > I'm looking for the latest documentation for setting up a Managed Block > > Device storage domain so that I can move some of my VM images to ceph > > rbd. > > > > I found this: > > > >
[ovirt-users] Re: Latest ManagedBlockDevice documentation
Not sure about this, adding +Yedidyah Bar David On Wed, Sep 30, 2020 at 3:04 PM Michael Thomas wrote: > > I hadn't installed the necessary packages when the engine was first > installed. > > However, running 'engine-setup --reconfigure-optional-components' > doesn't work at the moment because (by design) my engine does not have a > network route outside of the cluster. It fails with: > > [ INFO ] DNF Errors during downloading metadata for repository 'AppStream': > - Curl error (7): Couldn't connect to server for > http://mirrorlist.centos.org/?release=8=x86_64=AppStream=$infra > [Failed to connect to mirrorlist.centos.org port 80: Network is unreachable] > [ ERROR ] DNF Failed to download metadata for repo 'AppStream': Cannot > prepare internal mirrorlist: Curl error (7): Couldn't connect to server > for > http://mirrorlist.centos.org/?release=8=x86_64=AppStream=$infra > [Failed to connect to mirrorlist.centos.org port 80: Network is unreachable] > > > I have a proxy set in the engine's /etc/dnf/dnf.conf, but it doesn't > seem to be obeyed when running engine-setup. Is there another way that > I can get engine-setup to use a proxy? > > --Mike > > > On 9/30/20 2:19 AM, Benny Zlotnik wrote: > > When you ran `engine-setup` did you enable cinderlib preview (it will > > not be enabled by default)? > > It should handle the creation of the database automatically, if you > > didn't you can enable it by running: > > `engine-setup --reconfigure-optional-components` > > > > > > On Wed, Sep 30, 2020 at 1:58 AM Michael Thomas wrote: > >> > >> Hi Benny, > >> > >> Thanks for the confirmation. I've installed openstack-ussuri and ceph > >> Octopus. Then I tried using these instructions, as well as the deep > >> dive that Eyal has posted at https://www.youtube.com/watch?v=F3JttBkjsX8. > >> > >> I've done this a couple of times, and each time the engine fails when I > >> try to add the new managed block storage domain. The error on the > >> screen indicates that it can't connect to the cinder database. The > >> error in the engine log is: > >> > >> 2020-09-29 17:02:11,859-05 WARN > >> [org.ovirt.engine.core.bll.storage.domain.AddManagedBlockStorageDomainCommand] > >> (default task-2) [d519088c-7956-4078-b5cf-156e5b3f1e59] Validation of > >> action 'AddManagedBlockStorageDomain' failed for user > >> admin@internal-authz. Reasons: > >> VAR__TYPE__STORAGE__DOMAIN,VAR__ACTION__ADD,ACTION_TYPE_FAILED_CINDERLIB_DATA_BASE_REQUIRED,ACTION_TYPE_FAILED_CINDERLIB_DATA_BASE_REQUIRED > >> > >> I had created the db on the engine with this command: > >> > >> su - postgres -c "psql -d template1 -c \"create database cinder owner > >> engine template template0 encoding 'UTF8' lc_collate 'en_US.UTF-8' > >> lc_ctype 'en_US.UTF-8';\"" > >> > >> ...and added the following to the end of /var/lib/pgsql/data/pg_hba.conf: > >> > >> hostcinder engine ::0/0 md5 > >> hostcinder engine 0.0.0.0/0 md5 > >> > >> Is there anywhere else I should look to find out what may have gone wrong? > >> > >> --Mike > >> > >> On 9/29/20 3:34 PM, Benny Zlotnik wrote: > >>> The feature is currently in tech preview, but it's being worked on. > >>> The feature page is outdated, but I believe this is what most users > >>> in the mailing list were using. We held off on updating it because the > >>> installation instructions have been a moving target, but it is more > >>> stable now and I will update it soon. > >>> > >>> Specifically speaking, the openstack version should be updated to > >>> train (it is likely ussuri works fine too, but I haven't tried it) and > >>> cinderlib has an RPM now (python3-cinderlib)[1], so it can be > >>> installed instead of using pip, same goes for os-brick. The rest of > >>> the information is valid. > >>> > >>> > >>> [1] > >>> http://mirror.centos.org/centos/8/cloud/x86_64/openstack-ussuri/Packages/p/ > >>> > >>> On Tue, Sep 29, 2020 at 10:37 PM Michael Thomas wrote: > > I'm looking for the latest documentation for setting up a Managed Block > Device storage domain so that I can move some of my VM images to ceph > rbd. > > I found this: > > https://ovirt.org/develop/release-management/features/storage/cinderlib-integration.html > > ...but it has a big note at the top that it is "...not user > documentation and should not be treated as such." > > The oVirt administration guide[1] does not talk about managed block > devices. > > I've found a few mailing list threads that discuss people setting up a > Managed Block Device with ceph, but didn't see any links to > documentation steps that folks were following. > > Is the Managed Block Storage domain a supported feature in oVirt 4.4.2, > and if so, where is the documentation for using it? > > --Mike > [1]ovirt.org/documentation/administration_guide/ >
[ovirt-users] Re: Latest ManagedBlockDevice documentation
I hadn't installed the necessary packages when the engine was first installed. However, running 'engine-setup --reconfigure-optional-components' doesn't work at the moment because (by design) my engine does not have a network route outside of the cluster. It fails with: [ INFO ] DNF Errors during downloading metadata for repository 'AppStream': - Curl error (7): Couldn't connect to server for http://mirrorlist.centos.org/?release=8=x86_64=AppStream=$infra [Failed to connect to mirrorlist.centos.org port 80: Network is unreachable] [ ERROR ] DNF Failed to download metadata for repo 'AppStream': Cannot prepare internal mirrorlist: Curl error (7): Couldn't connect to server for http://mirrorlist.centos.org/?release=8=x86_64=AppStream=$infra [Failed to connect to mirrorlist.centos.org port 80: Network is unreachable] I have a proxy set in the engine's /etc/dnf/dnf.conf, but it doesn't seem to be obeyed when running engine-setup. Is there another way that I can get engine-setup to use a proxy? --Mike On 9/30/20 2:19 AM, Benny Zlotnik wrote: When you ran `engine-setup` did you enable cinderlib preview (it will not be enabled by default)? It should handle the creation of the database automatically, if you didn't you can enable it by running: `engine-setup --reconfigure-optional-components` On Wed, Sep 30, 2020 at 1:58 AM Michael Thomas wrote: Hi Benny, Thanks for the confirmation. I've installed openstack-ussuri and ceph Octopus. Then I tried using these instructions, as well as the deep dive that Eyal has posted at https://www.youtube.com/watch?v=F3JttBkjsX8. I've done this a couple of times, and each time the engine fails when I try to add the new managed block storage domain. The error on the screen indicates that it can't connect to the cinder database. The error in the engine log is: 2020-09-29 17:02:11,859-05 WARN [org.ovirt.engine.core.bll.storage.domain.AddManagedBlockStorageDomainCommand] (default task-2) [d519088c-7956-4078-b5cf-156e5b3f1e59] Validation of action 'AddManagedBlockStorageDomain' failed for user admin@internal-authz. Reasons: VAR__TYPE__STORAGE__DOMAIN,VAR__ACTION__ADD,ACTION_TYPE_FAILED_CINDERLIB_DATA_BASE_REQUIRED,ACTION_TYPE_FAILED_CINDERLIB_DATA_BASE_REQUIRED I had created the db on the engine with this command: su - postgres -c "psql -d template1 -c \"create database cinder owner engine template template0 encoding 'UTF8' lc_collate 'en_US.UTF-8' lc_ctype 'en_US.UTF-8';\"" ...and added the following to the end of /var/lib/pgsql/data/pg_hba.conf: hostcinder engine ::0/0 md5 hostcinder engine 0.0.0.0/0 md5 Is there anywhere else I should look to find out what may have gone wrong? --Mike On 9/29/20 3:34 PM, Benny Zlotnik wrote: The feature is currently in tech preview, but it's being worked on. The feature page is outdated, but I believe this is what most users in the mailing list were using. We held off on updating it because the installation instructions have been a moving target, but it is more stable now and I will update it soon. Specifically speaking, the openstack version should be updated to train (it is likely ussuri works fine too, but I haven't tried it) and cinderlib has an RPM now (python3-cinderlib)[1], so it can be installed instead of using pip, same goes for os-brick. The rest of the information is valid. [1] http://mirror.centos.org/centos/8/cloud/x86_64/openstack-ussuri/Packages/p/ On Tue, Sep 29, 2020 at 10:37 PM Michael Thomas wrote: I'm looking for the latest documentation for setting up a Managed Block Device storage domain so that I can move some of my VM images to ceph rbd. I found this: https://ovirt.org/develop/release-management/features/storage/cinderlib-integration.html ...but it has a big note at the top that it is "...not user documentation and should not be treated as such." The oVirt administration guide[1] does not talk about managed block devices. I've found a few mailing list threads that discuss people setting up a Managed Block Device with ceph, but didn't see any links to documentation steps that folks were following. Is the Managed Block Storage domain a supported feature in oVirt 4.4.2, and if so, where is the documentation for using it? --Mike [1]ovirt.org/documentation/administration_guide/ ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/KHCLXVOCELHOR3G7SH3GDPGRKITCW7UY/ ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html
[ovirt-users] Re: Latest ManagedBlockDevice documentation
When you ran `engine-setup` did you enable cinderlib preview (it will not be enabled by default)? It should handle the creation of the database automatically, if you didn't you can enable it by running: `engine-setup --reconfigure-optional-components` On Wed, Sep 30, 2020 at 1:58 AM Michael Thomas wrote: > > Hi Benny, > > Thanks for the confirmation. I've installed openstack-ussuri and ceph > Octopus. Then I tried using these instructions, as well as the deep > dive that Eyal has posted at https://www.youtube.com/watch?v=F3JttBkjsX8. > > I've done this a couple of times, and each time the engine fails when I > try to add the new managed block storage domain. The error on the > screen indicates that it can't connect to the cinder database. The > error in the engine log is: > > 2020-09-29 17:02:11,859-05 WARN > [org.ovirt.engine.core.bll.storage.domain.AddManagedBlockStorageDomainCommand] > (default task-2) [d519088c-7956-4078-b5cf-156e5b3f1e59] Validation of > action 'AddManagedBlockStorageDomain' failed for user > admin@internal-authz. Reasons: > VAR__TYPE__STORAGE__DOMAIN,VAR__ACTION__ADD,ACTION_TYPE_FAILED_CINDERLIB_DATA_BASE_REQUIRED,ACTION_TYPE_FAILED_CINDERLIB_DATA_BASE_REQUIRED > > I had created the db on the engine with this command: > > su - postgres -c "psql -d template1 -c \"create database cinder owner > engine template template0 encoding 'UTF8' lc_collate 'en_US.UTF-8' > lc_ctype 'en_US.UTF-8';\"" > > ...and added the following to the end of /var/lib/pgsql/data/pg_hba.conf: > > hostcinder engine ::0/0 md5 > hostcinder engine 0.0.0.0/0 md5 > > Is there anywhere else I should look to find out what may have gone wrong? > > --Mike > > On 9/29/20 3:34 PM, Benny Zlotnik wrote: > > The feature is currently in tech preview, but it's being worked on. > > The feature page is outdated, but I believe this is what most users > > in the mailing list were using. We held off on updating it because the > > installation instructions have been a moving target, but it is more > > stable now and I will update it soon. > > > > Specifically speaking, the openstack version should be updated to > > train (it is likely ussuri works fine too, but I haven't tried it) and > > cinderlib has an RPM now (python3-cinderlib)[1], so it can be > > installed instead of using pip, same goes for os-brick. The rest of > > the information is valid. > > > > > > [1] > > http://mirror.centos.org/centos/8/cloud/x86_64/openstack-ussuri/Packages/p/ > > > > On Tue, Sep 29, 2020 at 10:37 PM Michael Thomas wrote: > >> > >> I'm looking for the latest documentation for setting up a Managed Block > >> Device storage domain so that I can move some of my VM images to ceph rbd. > >> > >> I found this: > >> > >> https://ovirt.org/develop/release-management/features/storage/cinderlib-integration.html > >> > >> ...but it has a big note at the top that it is "...not user > >> documentation and should not be treated as such." > >> > >> The oVirt administration guide[1] does not talk about managed block > >> devices. > >> > >> I've found a few mailing list threads that discuss people setting up a > >> Managed Block Device with ceph, but didn't see any links to > >> documentation steps that folks were following. > >> > >> Is the Managed Block Storage domain a supported feature in oVirt 4.4.2, > >> and if so, where is the documentation for using it? > >> > >> --Mike > >> [1]ovirt.org/documentation/administration_guide/ > >> ___ > >> Users mailing list -- users@ovirt.org > >> To unsubscribe send an email to users-le...@ovirt.org > >> Privacy Statement: https://www.ovirt.org/privacy-policy.html > >> oVirt Code of Conduct: > >> https://www.ovirt.org/community/about/community-guidelines/ > >> List Archives: > >> https://lists.ovirt.org/archives/list/users@ovirt.org/message/KHCLXVOCELHOR3G7SH3GDPGRKITCW7UY/ > > > ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZHHOMSMDUWBHXZC77SQE4R3MAK7M4ZCN/
[ovirt-users] Re: Latest ManagedBlockDevice documentation
Hi Benny, Thanks for the confirmation. I've installed openstack-ussuri and ceph Octopus. Then I tried using these instructions, as well as the deep dive that Eyal has posted at https://www.youtube.com/watch?v=F3JttBkjsX8. I've done this a couple of times, and each time the engine fails when I try to add the new managed block storage domain. The error on the screen indicates that it can't connect to the cinder database. The error in the engine log is: 2020-09-29 17:02:11,859-05 WARN [org.ovirt.engine.core.bll.storage.domain.AddManagedBlockStorageDomainCommand] (default task-2) [d519088c-7956-4078-b5cf-156e5b3f1e59] Validation of action 'AddManagedBlockStorageDomain' failed for user admin@internal-authz. Reasons: VAR__TYPE__STORAGE__DOMAIN,VAR__ACTION__ADD,ACTION_TYPE_FAILED_CINDERLIB_DATA_BASE_REQUIRED,ACTION_TYPE_FAILED_CINDERLIB_DATA_BASE_REQUIRED I had created the db on the engine with this command: su - postgres -c "psql -d template1 -c \"create database cinder owner engine template template0 encoding 'UTF8' lc_collate 'en_US.UTF-8' lc_ctype 'en_US.UTF-8';\"" ...and added the following to the end of /var/lib/pgsql/data/pg_hba.conf: hostcinder engine ::0/0 md5 hostcinder engine 0.0.0.0/0 md5 Is there anywhere else I should look to find out what may have gone wrong? --Mike On 9/29/20 3:34 PM, Benny Zlotnik wrote: The feature is currently in tech preview, but it's being worked on. The feature page is outdated, but I believe this is what most users in the mailing list were using. We held off on updating it because the installation instructions have been a moving target, but it is more stable now and I will update it soon. Specifically speaking, the openstack version should be updated to train (it is likely ussuri works fine too, but I haven't tried it) and cinderlib has an RPM now (python3-cinderlib)[1], so it can be installed instead of using pip, same goes for os-brick. The rest of the information is valid. [1] http://mirror.centos.org/centos/8/cloud/x86_64/openstack-ussuri/Packages/p/ On Tue, Sep 29, 2020 at 10:37 PM Michael Thomas wrote: I'm looking for the latest documentation for setting up a Managed Block Device storage domain so that I can move some of my VM images to ceph rbd. I found this: https://ovirt.org/develop/release-management/features/storage/cinderlib-integration.html ...but it has a big note at the top that it is "...not user documentation and should not be treated as such." The oVirt administration guide[1] does not talk about managed block devices. I've found a few mailing list threads that discuss people setting up a Managed Block Device with ceph, but didn't see any links to documentation steps that folks were following. Is the Managed Block Storage domain a supported feature in oVirt 4.4.2, and if so, where is the documentation for using it? --Mike [1]ovirt.org/documentation/administration_guide/ ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/KHCLXVOCELHOR3G7SH3GDPGRKITCW7UY/ ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/WUYG5H2T4ODBS3YCOTNHJMUBCKMFMATI/
[ovirt-users] Re: Latest ManagedBlockDevice documentation
The feature is currently in tech preview, but it's being worked on. The feature page is outdated, but I believe this is what most users in the mailing list were using. We held off on updating it because the installation instructions have been a moving target, but it is more stable now and I will update it soon. Specifically speaking, the openstack version should be updated to train (it is likely ussuri works fine too, but I haven't tried it) and cinderlib has an RPM now (python3-cinderlib)[1], so it can be installed instead of using pip, same goes for os-brick. The rest of the information is valid. [1] http://mirror.centos.org/centos/8/cloud/x86_64/openstack-ussuri/Packages/p/ On Tue, Sep 29, 2020 at 10:37 PM Michael Thomas wrote: > > I'm looking for the latest documentation for setting up a Managed Block > Device storage domain so that I can move some of my VM images to ceph rbd. > > I found this: > > https://ovirt.org/develop/release-management/features/storage/cinderlib-integration.html > > ...but it has a big note at the top that it is "...not user > documentation and should not be treated as such." > > The oVirt administration guide[1] does not talk about managed block devices. > > I've found a few mailing list threads that discuss people setting up a > Managed Block Device with ceph, but didn't see any links to > documentation steps that folks were following. > > Is the Managed Block Storage domain a supported feature in oVirt 4.4.2, > and if so, where is the documentation for using it? > > --Mike > [1]ovirt.org/documentation/administration_guide/ > ___ > Users mailing list -- users@ovirt.org > To unsubscribe send an email to users-le...@ovirt.org > Privacy Statement: https://www.ovirt.org/privacy-policy.html > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/users@ovirt.org/message/KHCLXVOCELHOR3G7SH3GDPGRKITCW7UY/ ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/VQ7QQOP5T6UBFRXGWHNUN2SYN2CBPIZZ/
