So I started looking in the logs and tried to follow along with the
code, but things didn't make sense and then I saw it's ovirt 4.3 which
makes things more complicated :)
Unfortunately because GUID is sent in the metadata the volume is
treated as a vdsm managed volume[2] for the udev rule generation and
it prepends the /dev/mapper prefix to an empty string as a result.
I don't have the vdsm logs, so I am not sure where exactly this fails,
but if it's after [4] it may be possible to workaround it with a vdsm
hook
In 4.4.6 we moved the udev rule triggering the volume mapping phase,
before starting the VM. But it could still not work because we check
the driver_volume_type in[1], and I saw it's "driver_volume_type":
"lightos" for lightbits
In theory it looks like it wouldn't take much to add support for your
driver in a future release (as it's pretty late for 4.5)
[1]
On Wed, Feb 23, 2022 at 12:44 PM Muli Ben-Yehuda <muli(a)lightbitslabs.com> wrote:
Certainly, thanks for your help!
I put cinderlib and engine.log here:
http://www.mulix.org/misc/ovirt-logs-20220223123641.tar.gz
If you grep for 'mulivm1' you will see for example:
2022-02-22 04:31:04,473-05 ERROR
[org.ovirt.engine.core.vdsbroker.vdsbroker.HotPlugDiskVDSCommand] (default task-10)
[36d8a122] Command 'HotPlugDiskVDSCommand(HostName = client1,
HotPlugDiskVDSParameters:{hostId='fc5c2860-36b1-4213-843f-10ca7b35556c',
vmId='e13f73a0-8e20-4ec3-837f-aeacc082c7aa',
diskId='d1e1286b-38cc-4d56-9d4e-f331ffbe830f', addressMap='[bus=0,
controller=0, unit=2, type=drive, target=0]'})' execution failed:
VDSGenericException: VDSErrorException: Failed to HotPlugDiskVDS, error = Failed to bind
/dev/mapper/ on to /var/run/libvirt/qemu/21-mulivm1.mapper.: Not a directory, code = 45
Please let me know what other information will be useful and I will prove.
Cheers,
Muli
On Wed, Feb 23, 2022 at 11:14 AM Benny Zlotnik <bzlotnik(a)redhat.com> wrote:
>
> Hi,
>
> We haven't tested this, and we do not have any code to handle nvme/tcp
> drivers, only iscsi and rbd. Given the path seen in the logs
> '/dev/mapper', it looks like it might require code changes to support
> this.
> Can you share cinderlib[1] and engine logs to see what is returned by
> the driver? I may be able to estimate what would be required (it's
> possible that it would be enough to just change the handling of the
> path in the engine)
>
> [1] /var/log/ovirt-engine/cinderlib/cinderlib//log
>
> On Wed, Feb 23, 2022 at 10:54 AM <muli(a)lightbitslabs.com> wrote:
> >
> > Hi everyone,
> >
> > We are trying to set up ovirt (4.3.10 at the moment, customer preference) to use
Lightbits (
https://www.lightbitslabs.com) storage via our openstack cinder driver with
cinderlib. The cinderlib and cinder driver bits are working fine but when ovirt tries to
attach the device to a VM we get the following error:
> >
> > libvirt: error : cannot create file
'/var/run/libvirt/qemu/18-mulivm1.dev/mapper/': Is a directory
> >
> > We get the same error regardless of whether I try to run the VM or try to attach
the device while it is running. The error appears to come from vdsm which passes
/dev/mapper as the prefered device?
> >
> > 2022-02-22 09:50:11,848-0500 INFO (vm/3ae7dcf4) [vdsm.api] FINISH
appropriateDevice return={'path': '/dev/mapper/', 'truesize':
'53687091200', 'apparentsize': '53687091200'} from=internal,
task_id=77f40c4e-733d-4d82-b418-aaeb6b912d39 (api:54)
> > 2022-02-22 09:50:11,849-0500 INFO (vm/3ae7dcf4) [vds] prepared volume path:
/dev/mapper/ (clientIF:510)
> >
> > Suggestions for how to debug this further? Is this a known issue? Did anyone get
nvme/tcp storage working with ovirt and/or vdsm?
> >
> > Thanks,
> > Muli
> >
> > _______________________________________________
> > Users mailing list -- users(a)ovirt.org
> > To unsubscribe send an email to users-leave(a)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/I3PAG5HMBHU...
>
Lightbits Labs
Lead the cloud-native data center transformation by delivering scalable and efficient
software defined storage that is easy to consume.
This message is sent in confidence for the addressee only. It may contain legally
privileged information. The contents are not to be disclosed to anyone other than the
addressee. Unauthorized recipients are requested to preserve this confidentiality, advise
the sender immediately of any error in transmission and delete the email from their
systems.