Re: [PATCH] storage: add RBD support to disk source pool translation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/25/2015 09:16 PM, John Ferlan wrote:
> My assumption without doing too much thinking is that at some point the
> virStorageBackendRBDRefreshPool will reconnect for you in the
> storageDriverAutostart path...
> 
> While not exactly the same, consider how the iSCSI pool handles uses the
> checkPool callback.
> 
> During storagePoolUpdateState, if the 'checkPool' callback determines
> the pool is active, then storagePoolUpdateState will call refreshPool
> with a NULL conn; otherwise, we wait for Autostart.
> 
> So perhaps if the RBD backend had a checkPool that only did some sort of
> cursory check to ensure there was the infrastructure necessary for the
> ensuing refreshPool to work.
> 
> Of course in the UpdateState path, 'conn == NULL', so the
> virStorageBackendRBDOpenRADOSConn won't be happy if it has authdata, but
> that's a decision you can make in your refreshPool callback... I don't
> have a conn, thus I cannot do "something".

Thanks a lot, that really helped.

Indeed the iSCSI pool do not require a conn because session state is
kept outside of libvirt, so a secret is not required by refreshPool when
called during storageStateInitialize.

While RBD backend requires the Rados connection for pretty much
anything, and has to pull a secret. Hence during storageStateInitialize
we cannot implement a checkPool or refreshPool without a conn handle.

Now I can understand why we can't have secret access until the
*Initialize loop completes, but during *Autostart it's fine. Only that
it's too late to recover domains.

Maybe we would need a new path here. We can't autostart the qemu driver
before attempting to reconnect, right, to prevent VMs running twice. But
then how could we get a callback in RBD backend to be invoked with a
valid conn before? Has this problem been addressed in an other way already?

I cannot see where the current infrastructure may allow that.
It would be nice that some drivers be considered 'essentials' and
initialized before. (Or even going dependency-based.)
How do you think this could evolve?


For now I'll dive in other drivers code to search for similar case, and
hardcode part of the init for in-house use... time constraints.

Cheers,

-- 
Thibault VINCENT - Lead System Engineer, Infrastructure -
Arkena | Phone: +33 1 58 68 62 38 | Mobile: +33 6 78 97 01 08
27 Blvd Hippolyte Marquès, 94200 Ivry-sur-Seine, France | www.arkena.com
Arkena - Ready to Play


Attachment: signature.asc
Description: OpenPGP digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]