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 06:21 AM, Thibault VINCENT wrote:
> On 09/06/2015 17:33, John Ferlan wrote:
>> I still think I need a tweak on what I posted as an update - the
>> libvirtd restart path is always a bit tricky. The 'pooltype' isn't
>> filled in at XML processing time and virStorageTranslateDiskSourcePool
>> is only called after XML processing (sigh), so relying on it won't work.
>>
>> Working to figure out something generic and will repost my patch.
> 
> John,
> 
> I got stuck on this and would appreciate some advice to deal with the
> restart. With a revised patch it's still impossible to get libvirtd
> reconnecting to VMs using RBD source pool, because the network pool
> is never active so early.
> 
> It goes like this :
> + qemuProcessReconnect
> ++ virStorageTranslateDiskSourcePool
> +++ virStoragePoolIsActive
> ++++ storagePoolIsActive = 0
> ++ goto error
> ++ qemuProcessStop
> 
> But seconds after it's seen as active.
> 
> Isn't it a bad idea to consider a failure at translating source pool
> as an error in this code path? It looks quite dangerous whatever
> the pool protocol may be. After all the domain is still happily
> running anyway.
> 
> Cheers
> 

Black magic - you have to go further in the call stack to what calls
qemuProcessReconnect to fully understand, but along the way I'll bet
storagePoolUpdateState is called

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".

HTH,

John

--
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]