On 05/23/2016 12:37 PM, Michal Privoznik wrote:
> On 23.05.2016 11:16, Maxim Nestratov wrote:
>> 24.02.2015 13:12, Daniel P. Berrange пишет:
>>
>>> The undefine operation should always be allowed to succeed
>>> regardless of whether any NVRAM file exists. ie we should
>>> not force the application
23.05.2016 19:37, Michal Privoznik пишет:
On 23.05.2016 11:16, Maxim Nestratov wrote:
24.02.2015 13:12, Daniel P. Berrange пишет:
The undefine operation should always be allowed to succeed
regardless of whether any NVRAM file exists. ie we should
not force the application to use the VIR_DOMAI
On 23.05.2016 11:16, Maxim Nestratov wrote:
> 24.02.2015 13:12, Daniel P. Berrange пишет:
>
>> The undefine operation should always be allowed to succeed
>> regardless of whether any NVRAM file exists. ie we should
>> not force the application to use the VIR_DOMAIN_UNDEFINE_NVRAM
>> flag. It is va
24.02.2015 13:12, Daniel P. Berrange пишет:
The undefine operation should always be allowed to succeed
regardless of whether any NVRAM file exists. ie we should
not force the application to use the VIR_DOMAIN_UNDEFINE_NVRAM
flag. It is valid for the app to decide it wants the NVRAM
file left on
On Wed, Feb 25, 2015 at 11:11:37AM +0100, Peter Krempa wrote:
> On Tue, Feb 24, 2015 at 17:46:12 +0100, Kashyap Chamarthy wrote:
> > On Tue, Feb 24, 2015 at 10:12:20AM +, Daniel P. Berrange wrote:
> > > The undefine operation should always be allowed to succeed
> > > regardless of whether any N
On Tue, Feb 24, 2015 at 05:46:12PM +0100, Kashyap Chamarthy wrote:
> On Tue, Feb 24, 2015 at 10:12:20AM +, Daniel P. Berrange wrote:
[. . .]
> Edit the Fedora 21 libvirt guest. Guest XML here[*]:
>
> $ virsh edit devstack
> [. . .]
>
> Try to add the below fragment under 'os' elemen
On Tue, Feb 24, 2015 at 17:46:12 +0100, Kashyap Chamarthy wrote:
> On Tue, Feb 24, 2015 at 10:12:20AM +, Daniel P. Berrange wrote:
> > The undefine operation should always be allowed to succeed
> > regardless of whether any NVRAM file exists. ie we should
> > not force the application to use th
On 02/24/2015 10:23 AM, Peter Krempa wrote:
> On Tue, Feb 24, 2015 at 15:11:28 +, Daniel Berrange wrote:
>> On Tue, Feb 24, 2015 at 04:07:02PM +0100, Peter Krempa wrote:
>>> On Tue, Feb 24, 2015 at 10:12:20 +, Daniel Berrange wrote:
The undefine operation should always be allowed to su
On Tue, Feb 24, 2015 at 10:12:20AM +, Daniel P. Berrange wrote:
> The undefine operation should always be allowed to succeed
> regardless of whether any NVRAM file exists. ie we should
> not force the application to use the VIR_DOMAIN_UNDEFINE_NVRAM
> flag. It is valid for the app to decide it
[/me still reading the complete discussion.]
On Tue, Feb 24, 2015 at 04:07:02PM +0100, Peter Krempa wrote:
[. . .]
> We have prior art in denying to undefine a domain that has information
> stored in libvirt-internal locations such as the managed save image and
> snapshot metadata.
>
> While it
On Tue, Feb 24, 2015 at 04:41:44PM +0100, Peter Krempa wrote:
> On Tue, Feb 24, 2015 at 15:31:14 +, Daniel Berrange wrote:
> > On Tue, Feb 24, 2015 at 04:23:41PM +0100, Peter Krempa wrote:
> > > The original motivation is apparently that we should not allow anything
> > > that would represent s
On Tue, Feb 24, 2015 at 15:54:24 +, Daniel Berrange wrote:
> On Tue, Feb 24, 2015 at 04:41:44PM +0100, Peter Krempa wrote:
> > On Tue, Feb 24, 2015 at 15:31:14 +, Daniel Berrange wrote:
> > > On Tue, Feb 24, 2015 at 04:23:41PM +0100, Peter Krempa wrote:
> > > > The original motivation is ap
On Tue, Feb 24, 2015 at 15:31:14 +, Daniel Berrange wrote:
> On Tue, Feb 24, 2015 at 04:23:41PM +0100, Peter Krempa wrote:
> > In that case we probably should have negated the logic here and delete
> > all the stuff by default and give the user option to leave the data
> > behind.
>
> I think
On Tue, Feb 24, 2015 at 04:23:41PM +0100, Peter Krempa wrote:
> In that case we probably should have negated the logic here and delete
> all the stuff by default and give the user option to leave the data
> behind.
I think that would have been even more unsatisfactory - the semantics
of undefine w
On Tue, Feb 24, 2015 at 15:11:28 +, Daniel Berrange wrote:
> On Tue, Feb 24, 2015 at 04:07:02PM +0100, Peter Krempa wrote:
> > On Tue, Feb 24, 2015 at 10:12:20 +, Daniel Berrange wrote:
> > > The undefine operation should always be allowed to succeed
> > > regardless of whether any NVRAM fi
On Tue, Feb 24, 2015 at 04:07:02PM +0100, Peter Krempa wrote:
> On Tue, Feb 24, 2015 at 10:12:20 +, Daniel Berrange wrote:
> > The undefine operation should always be allowed to succeed
> > regardless of whether any NVRAM file exists. ie we should
> > not force the application to use the VIR_DO
On Tue, Feb 24, 2015 at 10:12:20 +, Daniel Berrange wrote:
> The undefine operation should always be allowed to succeed
> regardless of whether any NVRAM file exists. ie we should
> not force the application to use the VIR_DOMAIN_UNDEFINE_NVRAM
> flag. It is valid for the app to decide it wants
The undefine operation should always be allowed to succeed
regardless of whether any NVRAM file exists. ie we should
not force the application to use the VIR_DOMAIN_UNDEFINE_NVRAM
flag. It is valid for the app to decide it wants the NVRAM
file left on disk, in the same way that disk images are left
18 matches
Mail list logo