On 06/09/2015 10:47 AM, Thibault VINCENT wrote: > On 09/06/2015 14:45, John Ferlan wrote: >> Your cover letter indicates you didn't find any bit of documentation, >> but I'll point out that the formatdomain.html.in describes the "<disk >> type='volume'.../>" and how the "<source..." are described in order to >> use a disk type volume.. > > It's a misunderstanding, I never wished to imply a lack of information > existed on how to use the feature. Actually it was the page that led > to testing type 'volume' with RBD backends and finding out it didn't > work yet. Hence supporting other pool type would not require an update > to the documentation, which was my message. Although it's true we > could mention what's not supported yet in that area. > >> There's no tests in this patch to "show" or "prove" that by simply >> adding this code that libvirt will generate the correct qemu command in >> order to find the disk and it's auth information. >> [...] >> That might be a good place to start to ensure you have a >> way to have the domain XML recognize what it is you want and the qemu >> command to include/find the disk for the domain. > > Understood, working on new tests and a proper implementation. > It turns out I overlooked a lot of problems. > >> Curiously that bz was generated because the domain >> XML didn't have the 'secrettype' defined so when formatting for a >> snapshot, there was an error. (OK - so you found this already...) > > Indeed. The lack of 'secrettype' prevented migrations because of this, > and your post came in timely. > > Thanks John > 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list