On 11/10/2015 08:19 AM, Pavel Hrdina wrote: > This fixes an issue where you need to manually refresh storage pool or > restart virt-manager in order to be able delete guest that is currently > installed. This affect remote connection and non-root users. > > Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1251400 > > Signed-off-by: Pavel Hrdina <phrdina@xxxxxxxxxx> > --- > virtinst/storage.py | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/virtinst/storage.py b/virtinst/storage.py > index e50b78f..21d21a6 100644 > --- a/virtinst/storage.py > +++ b/virtinst/storage.py > @@ -797,6 +797,8 @@ class StorageVolume(_StorageObject): > logging.debug("Using vol create flags=%s", createflags) > vol = self.pool.createXML(xml, createflags) > > + self.pool.refresh() > + > self._install_finished = True > t.join() > meter.end(self.capacity) > I don't think this patch actually fixes the reported issue... it doesn't do anything for me at least. The root problem here is that libvirt doesn't support event APIs for storage operations, and virt-manager no longer relentlessly polls the storage list since it sucks for high latency connections. The disk image is created behind virt-managers back, and nothing in virt-manager is catching that it's updated. Particularly the pool.refresh() call here isn't going to signal virt-manager in any way to update its internal pool/vol cache, so it won't be reflected in the app. We already have some hacks in place to deal with outdated cache in virt-manager, like we will request a pool/vol cache update when launching the new VM wizard. But in this particular case I don't think it's important enough to try and fix, we should just defer it until libvirt has storage event APIs. Thanks, Cole _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
