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

Re: [libvirt] [PATCH 3/3]: Implement logical stopPool and deletePool more fully



On Fri, Sep 19, 2008 at 10:27:33AM +0100, Daniel P. Berrange wrote:
> On Fri, Sep 19, 2008 at 10:37:30AM +0200, Chris Lalancette wrote:
> > This patch does a few things.
> > 
> > 1)  Clean up a bunch of comments which I believe are no longer valid, or just
> > slightly wrong
> 
> ACK
> 
> > 2)  Enable the stopPool command for the logical backend.  The comment in the
> > code worries about a situation where you try to "stop" the logical volume that
> > your rootfs is on, for example.  However, that situation is already taken care
> > of by the LVM tools; if the logical volume you try to stop is active, it will
> > throw an error saying that the LV is in use, and won't stop it.  Therefore, it
> > should be pretty safe to try to stop logical volumes; it will fail for ones that
> > are in use, but will stop volumes that have been properly torn down ahead of time.
> 
> Ok, that's the scenario I was concerned about, so looks safe to enable 
> this then.
> 
> > 3)  In deletePool, remove the -f from the vgremove command.  Besides the fact
> > that we probably don't usually want to force things, the -f option doesn't exist
> > prior to F-9, so this would fail on F-8, RHEL-5, etc.
> 
> Hmm, are you sure it won't prompt for a y/n confirmation ? IIRC, that was 
> the reason I put in the -f. Perhaps simply ensuring stdin is /dev/null
> takes care of that problem.

  Hum, I hope the behaviour of the command didn't changed that way
between RHEL-5/F-8 and now. I just committed but maybe we can make
sure to pass /dev/null, since that's the main specific option of
vgremove, I guess it will ask by default at least in recent versions.
I didn't find an easy way to nullify stdin in virRun, seems we need
to do another wrapper for virExec, or I'm mistaken.

> > 4)  In deletePool, implement pvremove of all source devices.  Note that this
> > should also be relatively safe; it will only pvremove devices that we had
> > previously pvcreate'd in createPool, which means they were all under control of
> > libvirt.  It will not pvremove devices on an LVM that you previously created,
> > but were just scanning with libvirt.
> 
> ACK.

  I commited that patch but apparently we need at least to check that
pool deletion still works on F-9/10, so that's not completely done

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel veillard com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/


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