[Engine-devel] Question about CloneVMFromSnapshot feature in context of shared disks and direct LUNs-based disks
8:38 a.m.
Hi all,
Following the upstream meeting dated Wednesday January 18th, 2012 -
I presented the clone VM from snpashot feature and we discussed the
feature behaviour.
Two issues that were raised are the behaviour of the feature in context
of shared disks and direct LUNs-based disks -
On one hand, if we copy&collapse such images - this may yield to data
corruption (think of a scenario where the source and destination VMs use
the same disk).
On the other hand - if we decide not to copy&collapse - the target VM
will have missing VM and its state will not totally reflect the logical
state.
One of the solution raises is to mark such disks (at the destination) as
unplugged, allowing the administrator the ability to plug them
(understanding of course the consequences).
I would like to receive inputs on this issue
Kind regards,
Yair
9:19 a.m.
On 19/01/12 08:38, Yair Zaslavsky wrote:
Hi all,
Following the upstream meeting dated Wednesday January 18th, 2012 -
I presented the clone VM from snpashot feature and we discussed the
feature behaviour.
Two issues that were raised are the behaviour of the feature in context
of shared disks and direct LUNs-based disks -
On one hand, if we copy&collapse such images - this may yield to data
corruption (think of a scenario where the source and destination VMs use
the same disk).
On the other hand - if we decide not to copy&collapse - the target VM
will have missing VM and its state will not totally reflect the logical
state.
One of the solution raises is to mark such disks (at the destination) as
unplugged, allowing the administrator the ability to plug them
(understanding of course the consequences).
I would like to receive inputs on this issue
Kind regards,
Yair
Hi Yair,
Some clarifications on the above issue.
Currently when taking a snapshot on a VM with shared disks or direct LUN
disk there are 3 optional behaviors:
1. Blocking the snapshot action. (User can not take a snapshot of the VM
if it has plugged shared or direct LUN disks)
2. Taking the snapshot and marking the shared disk and direct LUN disks
as unplugged (in the VM snapshot configuration) and marking the snapshot
state as partial.
3. Taking the snapshot of the VM as is, leaving the VM configuration
with plugged disks.
The issue with including these disks in the snapshot is that they are
not really being snapshotted, they are not capturing the point in time
we are trying to achieve in the snapshot.
Enabling the snapshot action in such a state is a bit misleading to the
user.
If we do allow taking the snapshot we should mark the snapshot as
partial to indicate that the snapshot did not capture the point in time
as the user intended.
I have no preference with regards to the second and third approach, the
second approach is a bit more safe, we basically force the user to plug
the disks and be sure that he knows what he is doing and the third
approach is less safe and less annoying to the user (he took the
snapshot, cloned it and wants to start the VM - don't require extra actions)
Kolesnik - please note when starting VM in a preview mode we should
mount the disks in read-only mode (if supported).
Livnat
10:25 a.m.
----- Original Message -----
From: "Livnat Peer" <lpeer(a)redhat.com>
To: "Yair Zaslavsky" <yzaslavs(a)redhat.com>, "Mike Kolesnik"
<mkolesni(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Thursday, January 19, 2012 9:19:52 AM
Subject: Re: [Engine-devel] Question about CloneVMFromSnapshot feature in context of
shared disks and direct
LUNs-based disks
On 19/01/12 08:38, Yair Zaslavsky wrote:
> Hi all,
> Following the upstream meeting dated Wednesday January 18th, 2012 -
> I presented the clone VM from snpashot feature and we discussed the
> feature behaviour.
>
> Two issues that were raised are the behaviour of the feature in
> context
> of shared disks and direct LUNs-based disks -
> On one hand, if we copy&collapse such images - this may yield to
> data
> corruption (think of a scenario where the source and destination
> VMs use
> the same disk).
> On the other hand - if we decide not to copy&collapse - the target
> VM
> will have missing VM and its state will not totally reflect the
> logical
> state.
> One of the solution raises is to mark such disks (at the
> destination) as
> unplugged, allowing the administrator the ability to plug them
> (understanding of course the consequences).
>
> I would like to receive inputs on this issue
>
>
> Kind regards,
>
> Yair
Hi Yair,
Some clarifications on the above issue.
Currently when taking a snapshot on a VM with shared disks or direct
LUN
disk there are 3 optional behaviors:
1. Blocking the snapshot action. (User can not take a snapshot of the
VM
if it has plugged shared or direct LUN disks)
2. Taking the snapshot and marking the shared disk and direct LUN
disks
as unplugged (in the VM snapshot configuration) and marking the
snapshot
state as partial.
3. Taking the snapshot of the VM as is, leaving the VM configuration
with plugged disks.
The issue with including these disks in the snapshot is that they are
not really being snapshotted, they are not capturing the point in
time
we are trying to achieve in the snapshot.
Enabling the snapshot action in such a state is a bit misleading to
the
user.
If we do allow taking the snapshot we should mark the snapshot as
partial to indicate that the snapshot did not capture the point in
time
as the user intended.
I have no preference with regards to the second and third approach,
the
second approach is a bit more safe, we basically force the user to
plug
the disks and be sure that he knows what he is doing and the third
approach is less safe and less annoying to the user (he took the
snapshot, cloned it and wants to start the VM - don't require extra
actions)
Kolesnik - please note when starting VM in a preview mode we should
mount the disks in read-only mode (if supported).
Livnat
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
+1 for option 3
10:32 a.m.
----- Original Message -----
----- Original Message -----
> From: "Livnat Peer" <lpeer(a)redhat.com>
> To: "Yair Zaslavsky" <yzaslavs(a)redhat.com>, "Mike
Kolesnik"
> <mkolesni(a)redhat.com>
> Cc: engine-devel(a)ovirt.org
> Sent: Thursday, January 19, 2012 9:19:52 AM
> Subject: Re: [Engine-devel] Question about CloneVMFromSnapshot
> feature in context of shared disks and direct
> LUNs-based disks
>
> On 19/01/12 08:38, Yair Zaslavsky wrote:
> > Hi all,
> > Following the upstream meeting dated Wednesday January 18th, 2012
> > -
> > I presented the clone VM from snpashot feature and we discussed
> > the
> > feature behaviour.
> >
> > Two issues that were raised are the behaviour of the feature in
> > context
> > of shared disks and direct LUNs-based disks -
> > On one hand, if we copy&collapse such images - this may yield to
> > data
> > corruption (think of a scenario where the source and destination
> > VMs use
> > the same disk).
> > On the other hand - if we decide not to copy&collapse - the
> > target
> > VM
> > will have missing VM and its state will not totally reflect the
> > logical
> > state.
> > One of the solution raises is to mark such disks (at the
> > destination) as
> > unplugged, allowing the administrator the ability to plug them
> > (understanding of course the consequences).
> >
> > I would like to receive inputs on this issue
> >
> >
> > Kind regards,
> >
> > Yair
>
> Hi Yair,
>
> Some clarifications on the above issue.
> Currently when taking a snapshot on a VM with shared disks or
> direct
> LUN
> disk there are 3 optional behaviors:
>
> 1. Blocking the snapshot action. (User can not take a snapshot of
> the
> VM
> if it has plugged shared or direct LUN disks)
>
> 2. Taking the snapshot and marking the shared disk and direct LUN
> disks
> as unplugged (in the VM snapshot configuration) and marking the
> snapshot
> state as partial.
>
> 3. Taking the snapshot of the VM as is, leaving the VM
> configuration
> with plugged disks.
>
>
> The issue with including these disks in the snapshot is that they
> are
> not really being snapshotted, they are not capturing the point in
> time
> we are trying to achieve in the snapshot.
>
> Enabling the snapshot action in such a state is a bit misleading to
> the
> user.
>
> If we do allow taking the snapshot we should mark the snapshot as
> partial to indicate that the snapshot did not capture the point in
> time
> as the user intended.
>
> I have no preference with regards to the second and third approach,
> the
> second approach is a bit more safe, we basically force the user to
> plug
> the disks and be sure that he knows what he is doing and the third
> approach is less safe and less annoying to the user (he took the
> snapshot, cloned it and wants to start the VM - don't require extra
> actions)
>
> Kolesnik - please note when starting VM in a preview mode we should
> mount the disks in read-only mode (if supported).
I don't understand this, can you please elaborate why and in which case?
The disk is plugged/unplugged?
What happens when you commit? It becomes r/w?
>
>
> Livnat
>
>
>
+1 for option 3
+1 for option 3 as well (also good with option 1, but I think this will hinder
usability).
Regards,
Mike
11:22 a.m.
New subject: [Engine-devel] Question about CloneVMFromSnapshot feature in context of shared disks and direct LUNs-based disks
----- Original Message -----
----- Original Message -----
>
>
> ----- Original Message -----
> > From: "Livnat Peer" <lpeer(a)redhat.com>
> > To: "Yair Zaslavsky" <yzaslavs(a)redhat.com>, "Mike
Kolesnik"
> > <mkolesni(a)redhat.com>
> > Cc: engine-devel(a)ovirt.org
> > Sent: Thursday, January 19, 2012 9:19:52 AM
> > Subject: Re: [Engine-devel] Question about CloneVMFromSnapshot
> > feature in context of shared disks and direct
> > LUNs-based disks
> >
> > On 19/01/12 08:38, Yair Zaslavsky wrote:
> > > Hi all,
> > > Following the upstream meeting dated Wednesday January 18th,
> > > 2012
> > > -
> > > I presented the clone VM from snpashot feature and we discussed
> > > the
> > > feature behaviour.
> > >
> > > Two issues that were raised are the behaviour of the feature in
> > > context
> > > of shared disks and direct LUNs-based disks -
> > > On one hand, if we copy&collapse such images - this may yield
> > > to
> > > data
> > > corruption (think of a scenario where the source and
> > > destination
> > > VMs use
> > > the same disk).
> > > On the other hand - if we decide not to copy&collapse - the
> > > target
> > > VM
> > > will have missing VM and its state will not totally reflect the
> > > logical
> > > state.
> > > One of the solution raises is to mark such disks (at the
> > > destination) as
> > > unplugged, allowing the administrator the ability to plug them
> > > (understanding of course the consequences).
> > >
> > > I would like to receive inputs on this issue
> > >
> > >
> > > Kind regards,
> > >
> > > Yair
> >
> > Hi Yair,
> >
> > Some clarifications on the above issue.
> > Currently when taking a snapshot on a VM with shared disks or
> > direct
> > LUN
> > disk there are 3 optional behaviors:
> >
> > 1. Blocking the snapshot action. (User can not take a snapshot of
> > the
> > VM
> > if it has plugged shared or direct LUN disks)
-1, user should be able to take snapshots.
Note that once we have integration with hardware side snapshots, we will be able to
snapshot direct LUNs (when supported).
> >
> > 2. Taking the snapshot and marking the shared disk and direct LUN
> > disks
> > as unplugged (in the VM snapshot configuration) and marking the
> > snapshot
> > state as partial.
+1, user has to specifically say 'I know that the direct LUN is not in the same state
as it was when I took the snapshot but I know what I'm doing and I want to run the
snapshot with the LUN as is'
> >
> > 3. Taking the snapshot of the VM as is, leaving the VM
> > configuration
> > with plugged disks.
-1, this will lead to accidental corruptions.
> >
> >
> > The issue with including these disks in the snapshot is that they
> > are
> > not really being snapshotted, they are not capturing the point in
> > time
> > we are trying to achieve in the snapshot.
> >
> > Enabling the snapshot action in such a state is a bit misleading
> > to
> > the
> > user.
> >
> > If we do allow taking the snapshot we should mark the snapshot as
> > partial to indicate that the snapshot did not capture the point
> > in
> > time
> > as the user intended.
+1, the user should be aware of what she did.
> >
> > I have no preference with regards to the second and third
> > approach,
> > the
> > second approach is a bit more safe, we basically force the user
> > to
> > plug
> > the disks and be sure that he knows what he is doing and the
> > third
> > approach is less safe and less annoying to the user (he took the
> > snapshot, cloned it and wants to start the VM - don't require
> > extra
> > actions)
> >
> > Kolesnik - please note when starting VM in a preview mode we
> > should
> > mount the disks in read-only mode (if supported).
Note that if the LUN contains a file system to be mounted and the disk is plugged in read
only mode the guest will likely have a kernel panic when trying to mount the fs, I'm
not sure this is the behaviour we want.
I don't understand this, can you please elaborate why and in which
case?
The disk is plugged/unplugged?
What happens when you commit? It becomes r/w?
No, you mark it as read-only in the configuration when you create the snapshot.
User would have to manually change this to r/w.
I'm not sure we should both mark it as unplugged and r/o (although this is the safest
option).
As it would be annoying to get the disk to actually work in r/w (plug + make r/w).
Andy, your thoughts on this?
> >
> >
> > Livnat
> >
> >
> >
>
> +1 for option 3
>
+1 for option 3 as well (also good with option 1, but I think this
will hinder usability).
Regards,
Mike
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
1:54 p.m.
On 01/19/2012 10:32 AM, Mike Kolesnik wrote:
----- Original Message -----
>
>
> ----- Original Message -----
>> From: "Livnat Peer" <lpeer(a)redhat.com>
>> To: "Yair Zaslavsky" <yzaslavs(a)redhat.com>, "Mike
Kolesnik"
>> <mkolesni(a)redhat.com>
>> Cc: engine-devel(a)ovirt.org
>> Sent: Thursday, January 19, 2012 9:19:52 AM
>> Subject: Re: [Engine-devel] Question about CloneVMFromSnapshot
>> feature in context of shared disks and direct
>> LUNs-based disks
>>
>> On 19/01/12 08:38, Yair Zaslavsky wrote:
>>> Hi all,
>>> Following the upstream meeting dated Wednesday January 18th, 2012
>>> -
>>> I presented the clone VM from snpashot feature and we discussed
>>> the
>>> feature behaviour.
>>>
>>> Two issues that were raised are the behaviour of the feature in
>>> context
>>> of shared disks and direct LUNs-based disks -
>>> On one hand, if we copy&collapse such images - this may yield to
>>> data
>>> corruption (think of a scenario where the source and destination
>>> VMs use
>>> the same disk).
>>> On the other hand - if we decide not to copy&collapse - the
>>> target
>>> VM
>>> will have missing VM and its state will not totally reflect the
>>> logical
>>> state.
>>> One of the solution raises is to mark such disks (at the
>>> destination) as
>>> unplugged, allowing the administrator the ability to plug them
>>> (understanding of course the consequences).
>>>
>>> I would like to receive inputs on this issue
>>>
>>>
>>> Kind regards,
>>>
>>> Yair
>>
>> Hi Yair,
>>
>> Some clarifications on the above issue.
>> Currently when taking a snapshot on a VM with shared disks or
>> direct
>> LUN
>> disk there are 3 optional behaviors:
>>
>> 1. Blocking the snapshot action. (User can not take a snapshot of
>> the
>> VM
>> if it has plugged shared or direct LUN disks)
>>
>> 2. Taking the snapshot and marking the shared disk and direct LUN
>> disks
>> as unplugged (in the VM snapshot configuration) and marking the
>> snapshot
>> state as partial.
>>
>> 3. Taking the snapshot of the VM as is, leaving the VM
>> configuration
>> with plugged disks.
>>
>>
>> The issue with including these disks in the snapshot is that they
>> are
>> not really being snapshotted, they are not capturing the point in
>> time
>> we are trying to achieve in the snapshot.
>>
>> Enabling the snapshot action in such a state is a bit misleading to
>> the
>> user.
>>
>> If we do allow taking the snapshot we should mark the snapshot as
>> partial to indicate that the snapshot did not capture the point in
>> time
>> as the user intended.
>>
>> I have no preference with regards to the second and third approach,
>> the
>> second approach is a bit more safe, we basically force the user to
>> plug
>> the disks and be sure that he knows what he is doing and the third
>> approach is less safe and less annoying to the user (he took the
>> snapshot, cloned it and wants to start the VM - don't require extra
>> actions)
>>
>> Kolesnik - please note when starting VM in a preview mode we should
>> mount the disks in read-only mode (if supported).
I don't understand this, can you please elaborate why and in which case?
The disk is plugged/unplugged?
What happens when you commit? It becomes r/w?
>>
>>
>> Livnat
>>
>>
>>
>
> +1 for option 3
>
+1 for option 3 as well (also good with option 1, but I think this will hinder
usability).
I agree with Mike - I think option one is too "aggressive" in
protecting
us, this is why I prefer 3. +1 on option 3
Regards,
Mike
2:04 p.m.
----- Original Message -----
On 01/19/2012 10:32 AM, Mike Kolesnik wrote:
>
>
> ----- Original Message -----
>>
>>
>> ----- Original Message -----
>>> From: "Livnat Peer" <lpeer(a)redhat.com>
>>> To: "Yair Zaslavsky" <yzaslavs(a)redhat.com>, "Mike
Kolesnik"
>>> <mkolesni(a)redhat.com>
>>> Cc: engine-devel(a)ovirt.org
>>> Sent: Thursday, January 19, 2012 9:19:52 AM
>>> Subject: Re: [Engine-devel] Question about CloneVMFromSnapshot
>>> feature in context of shared disks and direct
>>> LUNs-based disks
>>>
>>> On 19/01/12 08:38, Yair Zaslavsky wrote:
>>>> Hi all,
>>>> Following the upstream meeting dated Wednesday January 18th,
>>>> 2012
>>>> -
>>>> I presented the clone VM from snpashot feature and we discussed
>>>> the
>>>> feature behaviour.
>>>>
>>>> Two issues that were raised are the behaviour of the feature in
>>>> context
>>>> of shared disks and direct LUNs-based disks -
>>>> On one hand, if we copy&collapse such images - this may yield to
>>>> data
>>>> corruption (think of a scenario where the source and destination
>>>> VMs use
>>>> the same disk).
>>>> On the other hand - if we decide not to copy&collapse - the
>>>> target
>>>> VM
>>>> will have missing VM and its state will not totally reflect the
>>>> logical
>>>> state.
>>>> One of the solution raises is to mark such disks (at the
>>>> destination) as
>>>> unplugged, allowing the administrator the ability to plug them
>>>> (understanding of course the consequences).
>>>>
>>>> I would like to receive inputs on this issue
>>>>
>>>>
>>>> Kind regards,
>>>>
>>>> Yair
>>>
>>> Hi Yair,
>>>
>>> Some clarifications on the above issue.
>>> Currently when taking a snapshot on a VM with shared disks or
>>> direct
>>> LUN
>>> disk there are 3 optional behaviors:
>>>
>>> 1. Blocking the snapshot action. (User can not take a snapshot of
>>> the
>>> VM
>>> if it has plugged shared or direct LUN disks)
>>>
>>> 2. Taking the snapshot and marking the shared disk and direct LUN
>>> disks
>>> as unplugged (in the VM snapshot configuration) and marking the
>>> snapshot
>>> state as partial.
>>>
>>> 3. Taking the snapshot of the VM as is, leaving the VM
>>> configuration
>>> with plugged disks.
>>>
>>>
>>> The issue with including these disks in the snapshot is that they
>>> are
>>> not really being snapshotted, they are not capturing the point in
>>> time
>>> we are trying to achieve in the snapshot.
>>>
>>> Enabling the snapshot action in such a state is a bit misleading
>>> to
>>> the
>>> user.
>>>
>>> If we do allow taking the snapshot we should mark the snapshot as
>>> partial to indicate that the snapshot did not capture the point
>>> in
>>> time
>>> as the user intended.
>>>
>>> I have no preference with regards to the second and third
>>> approach,
>>> the
>>> second approach is a bit more safe, we basically force the user
>>> to
>>> plug
>>> the disks and be sure that he knows what he is doing and the
>>> third
>>> approach is less safe and less annoying to the user (he took the
>>> snapshot, cloned it and wants to start the VM - don't require
>>> extra
>>> actions)
>>>
>>> Kolesnik - please note when starting VM in a preview mode we
>>> should
>>> mount the disks in read-only mode (if supported).
>
> I don't understand this, can you please elaborate why and in which
> case?
> The disk is plugged/unplugged?
> What happens when you commit? It becomes r/w?
>
>>>
>>>
>>> Livnat
>>>
>>>
>>>
>>
>> +1 for option 3
>>
>
> +1 for option 3 as well (also good with option 1, but I think this
> will hinder usability).
I agree with Mike - I think option one is too "aggressive" in
protecting
us, this is why I prefer 3. +1 on option 3
This would only be acceptable if the disk is marked read only.
Just leaving the disk plugged means many users *will* corrupt their VMs.
That trumps the need to mark a checkbox if you want it available.
As I said before, readonly has its own problems and in fact, IMO the behaviour is even
more difficult to explain (yeah, you might corrupt the running VM if it's r/w so we
made it r/o and now if you start up your clone / preview you will get a kernel panic).
>
>
> Regards,
> Mike
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
8:41 p.m.
New subject: [Engine-devel] Question about CloneVMFromSnapshot feature in context of shared disks and direct LUNs-based disks
Top Posting:
From user POV I think that option 2 is the only one that make sense.
We try to do as much as we can,
and on each "problematic" case, we make
him aware and let him decide.
Miki
----- Original Message -----
From: "Ayal Baron" <abaron(a)redhat.com>
To: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Thursday, January 19, 2012 4:04:02 AM
Subject: Re: [Engine-devel] Question about CloneVMFromSnapshot feature in context of
shared disks and direct
LUNs-based disks
----- Original Message -----
> On 01/19/2012 10:32 AM, Mike Kolesnik wrote:
> >
> >
> > ----- Original Message -----
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Livnat Peer" <lpeer(a)redhat.com>
> >>> To: "Yair Zaslavsky" <yzaslavs(a)redhat.com>, "Mike
Kolesnik"
> >>> <mkolesni(a)redhat.com>
> >>> Cc: engine-devel(a)ovirt.org
> >>> Sent: Thursday, January 19, 2012 9:19:52 AM
> >>> Subject: Re: [Engine-devel] Question about CloneVMFromSnapshot
> >>> feature in context of shared disks and direct
> >>> LUNs-based disks
> >>>
> >>> On 19/01/12 08:38, Yair Zaslavsky wrote:
> >>>> Hi all,
> >>>> Following the upstream meeting dated Wednesday January 18th,
> >>>> 2012
> >>>> -
> >>>> I presented the clone VM from snpashot feature and we
> >>>> discussed
> >>>> the
> >>>> feature behaviour.
> >>>>
> >>>> Two issues that were raised are the behaviour of the feature
> >>>> in
> >>>> context
> >>>> of shared disks and direct LUNs-based disks -
> >>>> On one hand, if we copy&collapse such images - this may yield
> >>>> to
> >>>> data
> >>>> corruption (think of a scenario where the source and
> >>>> destination
> >>>> VMs use
> >>>> the same disk).
> >>>> On the other hand - if we decide not to copy&collapse - the
> >>>> target
> >>>> VM
> >>>> will have missing VM and its state will not totally reflect
> >>>> the
> >>>> logical
> >>>> state.
> >>>> One of the solution raises is to mark such disks (at the
> >>>> destination) as
> >>>> unplugged, allowing the administrator the ability to plug them
> >>>> (understanding of course the consequences).
> >>>>
> >>>> I would like to receive inputs on this issue
> >>>>
> >>>>
> >>>> Kind regards,
> >>>>
> >>>> Yair
> >>>
> >>> Hi Yair,
> >>>
> >>> Some clarifications on the above issue.
> >>> Currently when taking a snapshot on a VM with shared disks or
> >>> direct
> >>> LUN
> >>> disk there are 3 optional behaviors:
> >>>
> >>> 1. Blocking the snapshot action. (User can not take a snapshot
> >>> of
> >>> the
> >>> VM
> >>> if it has plugged shared or direct LUN disks)
> >>>
> >>> 2. Taking the snapshot and marking the shared disk and direct
> >>> LUN
> >>> disks
> >>> as unplugged (in the VM snapshot configuration) and marking the
> >>> snapshot
> >>> state as partial.
> >>>
> >>> 3. Taking the snapshot of the VM as is, leaving the VM
> >>> configuration
> >>> with plugged disks.
> >>>
> >>>
> >>> The issue with including these disks in the snapshot is that
> >>> they
> >>> are
> >>> not really being snapshotted, they are not capturing the point
> >>> in
> >>> time
> >>> we are trying to achieve in the snapshot.
> >>>
> >>> Enabling the snapshot action in such a state is a bit
> >>> misleading
> >>> to
> >>> the
> >>> user.
> >>>
> >>> If we do allow taking the snapshot we should mark the snapshot
> >>> as
> >>> partial to indicate that the snapshot did not capture the point
> >>> in
> >>> time
> >>> as the user intended.
> >>>
> >>> I have no preference with regards to the second and third
> >>> approach,
> >>> the
> >>> second approach is a bit more safe, we basically force the user
> >>> to
> >>> plug
> >>> the disks and be sure that he knows what he is doing and the
> >>> third
> >>> approach is less safe and less annoying to the user (he took
> >>> the
> >>> snapshot, cloned it and wants to start the VM - don't require
> >>> extra
> >>> actions)
> >>>
> >>> Kolesnik - please note when starting VM in a preview mode we
> >>> should
> >>> mount the disks in read-only mode (if supported).
> >
> > I don't understand this, can you please elaborate why and in
> > which
> > case?
> > The disk is plugged/unplugged?
> > What happens when you commit? It becomes r/w?
> >
> >>>
> >>>
> >>> Livnat
> >>>
> >>>
> >>>
> >>
> >> +1 for option 3
> >>
> >
> > +1 for option 3 as well (also good with option 1, but I think
> > this
> > will hinder usability).
> I agree with Mike - I think option one is too "aggressive" in
> protecting
> us, this is why I prefer 3. +1 on option 3
This would only be acceptable if the disk is marked read only.
Just leaving the disk plugged means many users *will* corrupt their
VMs.
That trumps the need to mark a checkbox if you want it available.
As I said before, readonly has its own problems and in fact, IMO the
behaviour is even more difficult to explain (yeah, you might corrupt
the running VM if it's r/w so we made it r/o and now if you start up
your clone / preview you will get a kernel panic).
> >
> >
> > Regards,
> > Mike
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
9:35 a.m.
New subject: [Engine-devel] Question about CloneVMFromSnapshot feature in context of shared disks and direct LUNs-based disks
----- Original Message -----
Top Posting:
From user POV I think that option 2 is the only one that make sense.
We try to do as much as we can,
and on each "problematic" case, we make him aware and let him decide.
Yep, +1.
Miki
----- Original Message -----
> From: "Ayal Baron" <abaron(a)redhat.com>
> To: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
> Cc: engine-devel(a)ovirt.org
> Sent: Thursday, January 19, 2012 4:04:02 AM
> Subject: Re: [Engine-devel] Question about CloneVMFromSnapshot
> feature in context of shared disks and direct
> LUNs-based disks
>
>
>
> ----- Original Message -----
> > On 01/19/2012 10:32 AM, Mike Kolesnik wrote:
> > >
> > >
> > > ----- Original Message -----
> > >>
> > >>
> > >> ----- Original Message -----
> > >>> From: "Livnat Peer" <lpeer(a)redhat.com>
> > >>> To: "Yair Zaslavsky" <yzaslavs(a)redhat.com>,
"Mike Kolesnik"
> > >>> <mkolesni(a)redhat.com>
> > >>> Cc: engine-devel(a)ovirt.org
> > >>> Sent: Thursday, January 19, 2012 9:19:52 AM
> > >>> Subject: Re: [Engine-devel] Question about
> > >>> CloneVMFromSnapshot
> > >>> feature in context of shared disks and direct
> > >>> LUNs-based disks
> > >>>
> > >>> On 19/01/12 08:38, Yair Zaslavsky wrote:
> > >>>> Hi all,
> > >>>> Following the upstream meeting dated Wednesday January 18th,
> > >>>> 2012
> > >>>> -
> > >>>> I presented the clone VM from snpashot feature and we
> > >>>> discussed
> > >>>> the
> > >>>> feature behaviour.
> > >>>>
> > >>>> Two issues that were raised are the behaviour of the feature
> > >>>> in
> > >>>> context
> > >>>> of shared disks and direct LUNs-based disks -
> > >>>> On one hand, if we copy&collapse such images - this may
> > >>>> yield
> > >>>> to
> > >>>> data
> > >>>> corruption (think of a scenario where the source and
> > >>>> destination
> > >>>> VMs use
> > >>>> the same disk).
> > >>>> On the other hand - if we decide not to copy&collapse -
the
> > >>>> target
> > >>>> VM
> > >>>> will have missing VM and its state will not totally reflect
> > >>>> the
> > >>>> logical
> > >>>> state.
> > >>>> One of the solution raises is to mark such disks (at the
> > >>>> destination) as
> > >>>> unplugged, allowing the administrator the ability to plug
> > >>>> them
> > >>>> (understanding of course the consequences).
> > >>>>
> > >>>> I would like to receive inputs on this issue
> > >>>>
> > >>>>
> > >>>> Kind regards,
> > >>>>
> > >>>> Yair
> > >>>
> > >>> Hi Yair,
> > >>>
> > >>> Some clarifications on the above issue.
> > >>> Currently when taking a snapshot on a VM with shared disks or
> > >>> direct
> > >>> LUN
> > >>> disk there are 3 optional behaviors:
> > >>>
> > >>> 1. Blocking the snapshot action. (User can not take a
> > >>> snapshot
> > >>> of
> > >>> the
> > >>> VM
> > >>> if it has plugged shared or direct LUN disks)
> > >>>
> > >>> 2. Taking the snapshot and marking the shared disk and direct
> > >>> LUN
> > >>> disks
> > >>> as unplugged (in the VM snapshot configuration) and marking
> > >>> the
> > >>> snapshot
> > >>> state as partial.
> > >>>
> > >>> 3. Taking the snapshot of the VM as is, leaving the VM
> > >>> configuration
> > >>> with plugged disks.
> > >>>
> > >>>
> > >>> The issue with including these disks in the snapshot is that
> > >>> they
> > >>> are
> > >>> not really being snapshotted, they are not capturing the
> > >>> point
> > >>> in
> > >>> time
> > >>> we are trying to achieve in the snapshot.
> > >>>
> > >>> Enabling the snapshot action in such a state is a bit
> > >>> misleading
> > >>> to
> > >>> the
> > >>> user.
> > >>>
> > >>> If we do allow taking the snapshot we should mark the
> > >>> snapshot
> > >>> as
> > >>> partial to indicate that the snapshot did not capture the
> > >>> point
> > >>> in
> > >>> time
> > >>> as the user intended.
> > >>>
> > >>> I have no preference with regards to the second and third
> > >>> approach,
> > >>> the
> > >>> second approach is a bit more safe, we basically force the
> > >>> user
> > >>> to
> > >>> plug
> > >>> the disks and be sure that he knows what he is doing and the
> > >>> third
> > >>> approach is less safe and less annoying to the user (he took
> > >>> the
> > >>> snapshot, cloned it and wants to start the VM - don't require
> > >>> extra
> > >>> actions)
> > >>>
> > >>> Kolesnik - please note when starting VM in a preview mode we
> > >>> should
> > >>> mount the disks in read-only mode (if supported).
> > >
> > > I don't understand this, can you please elaborate why and in
> > > which
> > > case?
> > > The disk is plugged/unplugged?
> > > What happens when you commit? It becomes r/w?
> > >
> > >>>
> > >>>
> > >>> Livnat
> > >>>
> > >>>
> > >>>
> > >>
> > >> +1 for option 3
> > >>
> > >
> > > +1 for option 3 as well (also good with option 1, but I think
> > > this
> > > will hinder usability).
> > I agree with Mike - I think option one is too "aggressive" in
> > protecting
> > us, this is why I prefer 3. +1 on option 3
>
> This would only be acceptable if the disk is marked read only.
> Just leaving the disk plugged means many users *will* corrupt their
> VMs.
> That trumps the need to mark a checkbox if you want it available.
>
> As I said before, readonly has its own problems and in fact, IMO
> the
> behaviour is even more difficult to explain (yeah, you might
> corrupt
> the running VM if it's r/w so we made it r/o and now if you start
> up
> your clone / preview you will get a kernel panic).
>
> > >
> > >
> > > Regards,
> > > Mike
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
12:01 p.m.
On 20/01/12 09:35, Ayal Baron wrote:
----- Original Message -----
> Top Posting:
>
> From user POV I think that option 2 is the only one that make sense.
> We try to do as much as we can,
> and on each "problematic" case, we make him aware and let him decide.
>
Yep, +1.
Trying to get to a conclusion here,
3 different people said on this thread that they think that from the
user perspective leaving the shared devices plugged is what they think
is the best behavior to the user. (Omer, Kolesnik, Yair)
On the other hand we have 2 people who think that protecting the user is
more important than leaving the VM configuration as it was in the
original VM (Miki, Ayal).
Ayal/Miki can you please specify what are we protecting the user from?
I think that because we are not snapshotting the shared disk and the
direct LUN they should not be part of the VM configuration (in the
snapshot) at all. we can not promise the user that the disk will be
there and if it is there we can not guarantee it is in the same state as
it was when we took the snapshot.
Another issue,
I can not see a reason to limit this feature to creating a VM from
snapshot and not a template? Almost no extra work is needed for
supporting templates as well.
Any reason not to?
Livnat
> Miki
>
>
>
> ----- Original Message -----
>> From: "Ayal Baron" <abaron(a)redhat.com>
>> To: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
>> Cc: engine-devel(a)ovirt.org
>> Sent: Thursday, January 19, 2012 4:04:02 AM
>> Subject: Re: [Engine-devel] Question about CloneVMFromSnapshot
>> feature in context of shared disks and direct
>> LUNs-based disks
>>
>>
>>
>> ----- Original Message -----
>>> On 01/19/2012 10:32 AM, Mike Kolesnik wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Livnat Peer" <lpeer(a)redhat.com>
>>>>>> To: "Yair Zaslavsky" <yzaslavs(a)redhat.com>,
"Mike Kolesnik"
>>>>>> <mkolesni(a)redhat.com>
>>>>>> Cc: engine-devel(a)ovirt.org
>>>>>> Sent: Thursday, January 19, 2012 9:19:52 AM
>>>>>> Subject: Re: [Engine-devel] Question about
>>>>>> CloneVMFromSnapshot
>>>>>> feature in context of shared disks and direct
>>>>>> LUNs-based disks
>>>>>>
>>>>>> On 19/01/12 08:38, Yair Zaslavsky wrote:
>>>>>>> Hi all,
>>>>>>> Following the upstream meeting dated Wednesday January 18th,
>>>>>>> 2012
>>>>>>> -
>>>>>>> I presented the clone VM from snpashot feature and we
>>>>>>> discussed
>>>>>>> the
>>>>>>> feature behaviour.
>>>>>>>
>>>>>>> Two issues that were raised are the behaviour of the feature
>>>>>>> in
>>>>>>> context
>>>>>>> of shared disks and direct LUNs-based disks -
>>>>>>> On one hand, if we copy&collapse such images - this may
>>>>>>> yield
>>>>>>> to
>>>>>>> data
>>>>>>> corruption (think of a scenario where the source and
>>>>>>> destination
>>>>>>> VMs use
>>>>>>> the same disk).
>>>>>>> On the other hand - if we decide not to copy&collapse -
the
>>>>>>> target
>>>>>>> VM
>>>>>>> will have missing VM and its state will not totally reflect
>>>>>>> the
>>>>>>> logical
>>>>>>> state.
>>>>>>> One of the solution raises is to mark such disks (at the
>>>>>>> destination) as
>>>>>>> unplugged, allowing the administrator the ability to plug
>>>>>>> them
>>>>>>> (understanding of course the consequences).
>>>>>>>
>>>>>>> I would like to receive inputs on this issue
>>>>>>>
>>>>>>>
>>>>>>> Kind regards,
>>>>>>>
>>>>>>> Yair
>>>>>>
>>>>>> Hi Yair,
>>>>>>
>>>>>> Some clarifications on the above issue.
>>>>>> Currently when taking a snapshot on a VM with shared disks or
>>>>>> direct
>>>>>> LUN
>>>>>> disk there are 3 optional behaviors:
>>>>>>
>>>>>> 1. Blocking the snapshot action. (User can not take a
>>>>>> snapshot
>>>>>> of
>>>>>> the
>>>>>> VM
>>>>>> if it has plugged shared or direct LUN disks)
>>>>>>
>>>>>> 2. Taking the snapshot and marking the shared disk and direct
>>>>>> LUN
>>>>>> disks
>>>>>> as unplugged (in the VM snapshot configuration) and marking
>>>>>> the
>>>>>> snapshot
>>>>>> state as partial.
>>>>>>
>>>>>> 3. Taking the snapshot of the VM as is, leaving the VM
>>>>>> configuration
>>>>>> with plugged disks.
>>>>>>
>>>>>>
>>>>>> The issue with including these disks in the snapshot is that
>>>>>> they
>>>>>> are
>>>>>> not really being snapshotted, they are not capturing the
>>>>>> point
>>>>>> in
>>>>>> time
>>>>>> we are trying to achieve in the snapshot.
>>>>>>
>>>>>> Enabling the snapshot action in such a state is a bit
>>>>>> misleading
>>>>>> to
>>>>>> the
>>>>>> user.
>>>>>>
>>>>>> If we do allow taking the snapshot we should mark the
>>>>>> snapshot
>>>>>> as
>>>>>> partial to indicate that the snapshot did not capture the
>>>>>> point
>>>>>> in
>>>>>> time
>>>>>> as the user intended.
>>>>>>
>>>>>> I have no preference with regards to the second and third
>>>>>> approach,
>>>>>> the
>>>>>> second approach is a bit more safe, we basically force the
>>>>>> user
>>>>>> to
>>>>>> plug
>>>>>> the disks and be sure that he knows what he is doing and the
>>>>>> third
>>>>>> approach is less safe and less annoying to the user (he took
>>>>>> the
>>>>>> snapshot, cloned it and wants to start the VM - don't
require
>>>>>> extra
>>>>>> actions)
>>>>>>
>>>>>> Kolesnik - please note when starting VM in a preview mode we
>>>>>> should
>>>>>> mount the disks in read-only mode (if supported).
>>>>
>>>> I don't understand this, can you please elaborate why and in
>>>> which
>>>> case?
>>>> The disk is plugged/unplugged?
>>>> What happens when you commit? It becomes r/w?
>>>>
>>>>>>
>>>>>>
>>>>>> Livnat
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> +1 for option 3
>>>>>
>>>>
>>>> +1 for option 3 as well (also good with option 1, but I think
>>>> this
>>>> will hinder usability).
>>> I agree with Mike - I think option one is too "aggressive" in
>>> protecting
>>> us, this is why I prefer 3. +1 on option 3
>>
>> This would only be acceptable if the disk is marked read only.
>> Just leaving the disk plugged means many users *will* corrupt their
>> VMs.
>> That trumps the need to mark a checkbox if you want it available.
>>
>> As I said before, readonly has its own problems and in fact, IMO
>> the
>> behaviour is even more difficult to explain (yeah, you might
>> corrupt
>> the running VM if it's r/w so we made it r/o and now if you start
>> up
>> your clone / preview you will get a kernel panic).
>>
>>>>
>>>>
>>>> Regards,
>>>> Mike
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
5:21 p.m.
On 01/20/2012 12:01 PM, Livnat Peer wrote:
On 20/01/12 09:35, Ayal Baron wrote:
>
>
> ----- Original Message -----
>> Top Posting:
>>
>> From user POV I think that option 2 is the only one that make sense.
>> We try to do as much as we can,
>> and on each "problematic" case, we make him aware and let him decide.
>>
>
> Yep, +1.
>
Trying to get to a conclusion here,
3 different people said on this thread that they think that from the
user perspective leaving the shared devices plugged is what they think
is the best behavior to the user. (Omer, Kolesnik, Yair)
On the other hand we have 2 people who think that protecting the user is
more important than leaving the VM configuration as it was in the
original VM (Miki, Ayal).
Ayal/Miki can you please specify what are we protecting the user from?
I think that because we are not snapshotting the shared disk and the
direct LUN they should not be part of the VM configuration (in the
snapshot) at all. we can not promise the user that the disk will be
there and if it is there we can not guarantee it is in the same state as
it was when we took the snapshot.
Another issue,
I can not see a reason to limit this feature to creating a VM from
snapshot and not a template? Almost no extra work is needed for
supporting templates as well.
I assume you meant, creating a VM from another VM (if it is down)?
It should be supported.
8:50 p.m.
Sorry guys if I was not clear or maybe I missed something...
Let's take a use case:
- User like to create a VM for instance Win 2008, and would like to attach a shared disk
to it.
- User liked to create multiple copies of this VM.
(all vms shared the same disk, and run same OS).
so do I do that in oVirt.... we can do either option 2 or 3.
Option 2 as I read it:
Taking the snapshot and marking the shared disk and direct LUN
disks as unplugged (in the VM snapshot configuration) and marking the snapshot state as
partial.
my understanding was:
1. we is clone the vm configuration as is.
2. we try to clone the different disks
3. if there is shared raw disk/direct LUN, we do not clone them, we "unplug"
them.
4. the (poor) user, will have to plug these vms manually, in order to assure connectivity
and raise awareness that these disks are "special". This is nice but not great.
Option 3 as I read it:
Taking the snapshot and marking the shared disk and direct LUN
disks as plugged (in the VM snapshot configuration) and marking these disks as read only.
my understanding was:
1. we is clone the vm configuration as is.
2. we try to clone the different disks
3. if there is shared raw disk/direct LUN, we do not clone them , we make them read
only(?), and they remain plugged.
4. user is happy.
5. only issue is how we have to make the user aware that these disks are shared/read
only???
if this is possible, I agree to vote for third option :)
You might want to have a look at:
http://www.symantec.com/connect/articles/building-vmware-shared-disk
(look at the configuration file in Vmware:
disk.locking = "FALSE"
diskLib.dataCacheMaxSize = "0"
#scsi1 data storage
scsi1.present = "TRUE"
scsi1.virtualDev = "lsilogic"
scsi1.sharedbus = "none"
scsi1:0.present = "TRUE"
scsi1:0.fileName = " D:\Virtual Machines\Shared Disk\SHARED-DISK.vmdk "
scsi1:0.mode = "independent-persistent"
scsi1:0.shared = "TRUE"
scsi1:0.redo = ""
The shared flag is set for shared file, indicating "no locking"
I would like to re-ephasize that the user does not know the snapshotting mechanics. He
would like to "copy" the VM as is. We have to do our best, and highlights the
issues/sensitive points he has to take care of.
does that make sense?
Miki
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Livnat Peer" <lpeer(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Friday, January 20, 2012 7:21:34 AM
Subject: Re: [Engine-devel] Question about CloneVMFromSnapshot feature in context of
shared disks and direct
LUNs-based disks
On 01/20/2012 12:01 PM, Livnat Peer wrote:
> On 20/01/12 09:35, Ayal Baron wrote:
>>
>>
>> ----- Original Message -----
>>> Top Posting:
>>>
>>> From user POV I think that option 2 is the only one that make
>>> sense.
>>> We try to do as much as we can,
>>> and on each "problematic" case, we make him aware and let him
>>> decide.
>>>
>>
>> Yep, +1.
>>
>
> Trying to get to a conclusion here,
> 3 different people said on this thread that they think that from
> the
> user perspective leaving the shared devices plugged is what they
> think
> is the best behavior to the user. (Omer, Kolesnik, Yair)
>
> On the other hand we have 2 people who think that protecting the
> user is
> more important than leaving the VM configuration as it was in the
> original VM (Miki, Ayal).
>
> Ayal/Miki can you please specify what are we protecting the user
> from?
>
>
> I think that because we are not snapshotting the shared disk and
> the
> direct LUN they should not be part of the VM configuration (in the
> snapshot) at all. we can not promise the user that the disk will be
> there and if it is there we can not guarantee it is in the same
> state as
> it was when we took the snapshot.
>
>
> Another issue,
>
> I can not see a reason to limit this feature to creating a VM from
> snapshot and not a template? Almost no extra work is needed for
> supporting templates as well.
I assume you meant, creating a VM from another VM (if it is down)?
It should be supported.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
11:37 p.m.
New subject: [Engine-devel] Question about CloneVMFromSnapshot feature in context of shared disks and direct LUNs-based disks
----- Original Message -----
Sorry guys if I was not clear or maybe I missed something...
Let's take a use case:
- User like to create a VM for instance Win 2008, and would like to
attach a shared disk to it.
- User liked to create multiple copies of this VM.
(all vms shared the same disk, and run same OS).
so do I do that in oVirt.... we can do either option 2 or 3.
Option 2 as I read it:
Taking the snapshot and marking the shared disk and direct LUN
disks as unplugged (in the VM snapshot configuration) and marking the
snapshot state as partial.
my understanding was:
1. we is clone the vm configuration as is.
2. we try to clone the different disks
3. if there is shared raw disk/direct LUN, we do not clone them, we
"unplug" them.
4. the (poor) user, will have to plug these vms manually, in order to
assure connectivity and raise awareness that these disks are
"special". This is nice but not great.
Correct
Option 3 as I read it:
Taking the snapshot and marking the shared disk and direct LUN
disks as plugged (in the VM snapshot configuration) and marking these
disks as read only.
my understanding was:
1. we is clone the vm configuration as is.
2. we try to clone the different disks
3. if there is shared raw disk/direct LUN, we do not clone them , we
make them read only(?), and they remain plugged.
4. user is happy.
5. only issue is how we have to make the user aware that these disks
are shared/read only???
if this is possible, I agree to vote for third option :)
This will become apparent to the user once he boots the machine and gets the kernel panic
:)
You might want to have a look at:
http://www.symantec.com/connect/articles/building-vmware-shared-disk
(look at the configuration file in Vmware:
disk.locking = "FALSE"
diskLib.dataCacheMaxSize = "0"
#scsi1 data storage
scsi1.present = "TRUE"
scsi1.virtualDev = "lsilogic"
scsi1.sharedbus = "none"
scsi1:0.present = "TRUE"
scsi1:0.fileName = " D:\Virtual Machines\Shared Disk\SHARED-DISK.vmdk
"
scsi1:0.mode = "independent-persistent"
scsi1:0.shared = "TRUE"
scsi1:0.redo = ""
The shared flag is set for shared file, indicating "no locking"
This is shared disk, what about RDM?
I would like to re-ephasize that the user does not know the
snapshotting mechanics. He would like to "copy" the VM as is. We
have to do our best, and highlights the issues/sensitive points he
has to take care of.
does that make sense?
Miki
----- Original Message -----
> From: "Itamar Heim" <iheim(a)redhat.com>
> To: "Livnat Peer" <lpeer(a)redhat.com>
> Cc: engine-devel(a)ovirt.org
> Sent: Friday, January 20, 2012 7:21:34 AM
> Subject: Re: [Engine-devel] Question about CloneVMFromSnapshot
> feature in context of shared disks and direct
> LUNs-based disks
>
> On 01/20/2012 12:01 PM, Livnat Peer wrote:
> > On 20/01/12 09:35, Ayal Baron wrote:
> >>
> >>
> >> ----- Original Message -----
> >>> Top Posting:
> >>>
> >>> From user POV I think that option 2 is the only one that make
> >>> sense.
> >>> We try to do as much as we can,
> >>> and on each "problematic" case, we make him aware and let
him
> >>> decide.
> >>>
> >>
> >> Yep, +1.
> >>
> >
> > Trying to get to a conclusion here,
> > 3 different people said on this thread that they think that from
> > the
> > user perspective leaving the shared devices plugged is what they
> > think
> > is the best behavior to the user. (Omer, Kolesnik, Yair)
> >
> > On the other hand we have 2 people who think that protecting the
> > user is
> > more important than leaving the VM configuration as it was in the
> > original VM (Miki, Ayal).
> >
> > Ayal/Miki can you please specify what are we protecting the user
> > from?
> >
> >
> > I think that because we are not snapshotting the shared disk and
> > the
> > direct LUN they should not be part of the VM configuration (in
> > the
> > snapshot) at all. we can not promise the user that the disk will
> > be
> > there and if it is there we can not guarantee it is in the same
> > state as
> > it was when we took the snapshot.
> >
> >
> > Another issue,
> >
> > I can not see a reason to limit this feature to creating a VM
> > from
> > snapshot and not a template? Almost no extra work is needed for
> > supporting templates as well.
>
> I assume you meant, creating a VM from another VM (if it is down)?
> It should be supported.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
11:51 p.m.
New subject: [Engine-devel] Question about CloneVMFromSnapshot feature in context of shared disks and direct LUNs-based disks
----- Original Message -----
From: "Ayal Baron" <abaron(a)redhat.com>
To: "Miki Kenneth" <mkenneth(a)redhat.com>
Cc: engine-devel(a)ovirt.org, "Itamar Heim" <iheim(a)redhat.com>
Sent: Friday, January 20, 2012 1:37:54 PM
Subject: Re: [Engine-devel] Question about CloneVMFromSnapshot feature in context of
shared disks and direct
LUNs-based disks
----- Original Message -----
> Sorry guys if I was not clear or maybe I missed something...
>
> Let's take a use case:
> - User like to create a VM for instance Win 2008, and would like to
> attach a shared disk to it.
> - User liked to create multiple copies of this VM.
> (all vms shared the same disk, and run same OS).
> so do I do that in oVirt.... we can do either option 2 or 3.
>
> Option 2 as I read it:
> Taking the snapshot and marking the shared disk and direct LUN
> disks as unplugged (in the VM snapshot configuration) and marking
> the
> snapshot state as partial.
>
> my understanding was:
> 1. we is clone the vm configuration as is.
> 2. we try to clone the different disks
> 3. if there is shared raw disk/direct LUN, we do not clone them, we
> "unplug" them.
> 4. the (poor) user, will have to plug these vms manually, in order
> to
> assure connectivity and raise awareness that these disks are
> "special". This is nice but not great.
Correct
>
> Option 3 as I read it:
> Taking the snapshot and marking the shared disk and direct LUN
> disks as plugged (in the VM snapshot configuration) and marking
> these
> disks as read only.
>
> my understanding was:
> 1. we is clone the vm configuration as is.
> 2. we try to clone the different disks
> 3. if there is shared raw disk/direct LUN, we do not clone them ,
> we
> make them read only(?), and they remain plugged.
> 4. user is happy.
> 5. only issue is how we have to make the user aware that these
> disks
> are shared/read only???
> if this is possible, I agree to vote for third option :)
This will become apparent to the user once he boots the machine and
gets the kernel panic :)
Of course, this is no acceptable!
>
> You might want to have a look at:
> http://www.symantec.com/connect/articles/building-vmware-shared-disk
> (look at the configuration file in Vmware:
> disk.locking = "FALSE"
> diskLib.dataCacheMaxSize = "0"
> #scsi1 data storage
> scsi1.present = "TRUE"
> scsi1.virtualDev = "lsilogic"
> scsi1.sharedbus = "none"
> scsi1:0.present = "TRUE"
> scsi1:0.fileName = " D:\Virtual Machines\Shared
> Disk\SHARED-DISK.vmdk
> "
> scsi1:0.mode = "independent-persistent"
> scsi1:0.shared = "TRUE"
> scsi1:0.redo = ""
> The shared flag is set for shared file, indicating "no locking"
This is shared disk, what about RDM?
Don't know, will try to find out.
>
> I would like to re-ephasize that the user does not know the
> snapshotting mechanics. He would like to "copy" the VM as is. We
> have to do our best, and highlights the issues/sensitive points he
> has to take care of.
>
>
> does that make sense?
>
> Miki
>
>
>
> ----- Original Message -----
> > From: "Itamar Heim" <iheim(a)redhat.com>
> > To: "Livnat Peer" <lpeer(a)redhat.com>
> > Cc: engine-devel(a)ovirt.org
> > Sent: Friday, January 20, 2012 7:21:34 AM
> > Subject: Re: [Engine-devel] Question about CloneVMFromSnapshot
> > feature in context of shared disks and direct
> > LUNs-based disks
> >
> > On 01/20/2012 12:01 PM, Livnat Peer wrote:
> > > On 20/01/12 09:35, Ayal Baron wrote:
> > >>
> > >>
> > >> ----- Original Message -----
> > >>> Top Posting:
> > >>>
> > >>> From user POV I think that option 2 is the only one that
> > >>> make
> > >>> sense.
> > >>> We try to do as much as we can,
> > >>> and on each "problematic" case, we make him aware and
let him
> > >>> decide.
> > >>>
> > >>
> > >> Yep, +1.
> > >>
> > >
> > > Trying to get to a conclusion here,
> > > 3 different people said on this thread that they think that
> > > from
> > > the
> > > user perspective leaving the shared devices plugged is what
> > > they
> > > think
> > > is the best behavior to the user. (Omer, Kolesnik, Yair)
> > >
> > > On the other hand we have 2 people who think that protecting
> > > the
> > > user is
> > > more important than leaving the VM configuration as it was in
> > > the
> > > original VM (Miki, Ayal).
> > >
> > > Ayal/Miki can you please specify what are we protecting the
> > > user
> > > from?
> > >
> > >
> > > I think that because we are not snapshotting the shared disk
> > > and
> > > the
> > > direct LUN they should not be part of the VM configuration (in
> > > the
> > > snapshot) at all. we can not promise the user that the disk
> > > will
> > > be
> > > there and if it is there we can not guarantee it is in the same
> > > state as
> > > it was when we took the snapshot.
> > >
> > >
> > > Another issue,
> > >
> > > I can not see a reason to limit this feature to creating a VM
> > > from
> > > snapshot and not a template? Almost no extra work is needed for
> > > supporting templates as well.
> >
> > I assume you meant, creating a VM from another VM (if it is
> > down)?
> > It should be supported.
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
9:26 a.m.
On 20/01/12 17:21, Itamar Heim wrote:
On 01/20/2012 12:01 PM, Livnat Peer wrote:
> On 20/01/12 09:35, Ayal Baron wrote:
>>
>>
>> ----- Original Message -----
>>> Top Posting:
>>>
>>> From user POV I think that option 2 is the only one that make sense.
>>> We try to do as much as we can,
>>> and on each "problematic" case, we make him aware and let him
decide.
>>>
>>
>> Yep, +1.
>>
>
> Trying to get to a conclusion here,
> 3 different people said on this thread that they think that from the
> user perspective leaving the shared devices plugged is what they think
> is the best behavior to the user. (Omer, Kolesnik, Yair)
>
> On the other hand we have 2 people who think that protecting the user is
> more important than leaving the VM configuration as it was in the
> original VM (Miki, Ayal).
>
> Ayal/Miki can you please specify what are we protecting the user from?
>
>
> I think that because we are not snapshotting the shared disk and the
> direct LUN they should not be part of the VM configuration (in the
> snapshot) at all. we can not promise the user that the disk will be
> there and if it is there we can not guarantee it is in the same state as
> it was when we took the snapshot.
>
>
> Another issue,
>
> I can not see a reason to limit this feature to creating a VM from
> snapshot and not a template? Almost no extra work is needed for
> supporting templates as well.
I assume you meant, creating a VM from another VM (if it is down)?
It should be supported.
Actually I meant creating a Template from Snapshot.
What you suggested is creating a VM from VM.
Although I see how the two are connected, I think they should be modeled
as two different API calls.
There is a difference in the flow, behavior, locks and parameters
between the two.
Behavior:
- Original VM has to be down for creating a VM from VM, not the case for
creating a VM from snapshot.
parameters:
- Creating VM from snapshot should support getting a snapshot-ID,
Creating VM from VM get a VM id
Locks:
- When creating a VM from VM, we need to lock the original VM as a
whole, we can not edit the VM, take snapshot or any other VM level
action while such operation is active.
While for creating the VM from snapshot we can take more fine-grained
locks (only image related locks).
Implementation:
Well it is simply another implementation.
Livnat
11:26 a.m.
On 01/22/2012 09:26 AM, Livnat Peer wrote:
On 20/01/12 17:21, Itamar Heim wrote:
> On 01/20/2012 12:01 PM, Livnat Peer wrote:
>> On 20/01/12 09:35, Ayal Baron wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> Top Posting:
>>>>
>>>> From user POV I think that option 2 is the only one that make sense.
>>>> We try to do as much as we can,
>>>> and on each "problematic" case, we make him aware and let him
decide.
>>>>
>>>
>>> Yep, +1.
>>>
>>
>> Trying to get to a conclusion here,
>> 3 different people said on this thread that they think that from the
>> user perspective leaving the shared devices plugged is what they think
>> is the best behavior to the user. (Omer, Kolesnik, Yair)
>>
>> On the other hand we have 2 people who think that protecting the user is
>> more important than leaving the VM configuration as it was in the
>> original VM (Miki, Ayal).
>>
>> Ayal/Miki can you please specify what are we protecting the user from?
>>
>>
>> I think that because we are not snapshotting the shared disk and the
>> direct LUN they should not be part of the VM configuration (in the
>> snapshot) at all. we can not promise the user that the disk will be
>> there and if it is there we can not guarantee it is in the same state as
>> it was when we took the snapshot.
>>
>>
>> Another issue,
>>
>> I can not see a reason to limit this feature to creating a VM from
>> snapshot and not a template? Almost no extra work is needed for
>> supporting templates as well.
>
> I assume you meant, creating a VM from another VM (if it is down)?
> It should be supported.
Actually I meant creating a Template from Snapshot.
Livnat - I think that in case
of creating a template from snapshot we
should should have new API/Command, that will probably have lots in
common with Create VM from snapshot.
What you suggested is creating a VM from VM.
Although I see how the two are connected, I think they should be modeled
as two different API calls.
There is a difference in the flow, behavior, locks and parameters
between the two.
Behavior:
- Original VM has to be down for creating a VM from VM, not the case for
creating a VM from snapshot.
parameters:
- Creating VM from snapshot should support getting a snapshot-ID,
Creating VM from VM get a VM id
Locks:
- When creating a VM from VM, we need to lock the original VM as a
whole, we can not edit the VM, take snapshot or any other VM level
action while such operation is active.
While for creating the VM from snapshot we can take more fine-grained
locks (only image related locks).
Implementation:
Well it is simply another implementation.
+1 on Livnat's explanation - I do see
a (design/implementation wise) an
option for some code reuse, but IMHO - this should be a new command with
new API modelling
Livnat
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
12:15 p.m.
----- Original Message -----
On 01/22/2012 09:26 AM, Livnat Peer wrote:
> On 20/01/12 17:21, Itamar Heim wrote:
>> On 01/20/2012 12:01 PM, Livnat Peer wrote:
>>> On 20/01/12 09:35, Ayal Baron wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> Top Posting:
>>>>>
>>>>> From user POV I think that option 2 is the only one that make
>>>>> sense.
>>>>> We try to do as much as we can,
>>>>> and on each "problematic" case, we make him aware and let
him
>>>>> decide.
>>>>>
>>>>
>>>> Yep, +1.
>>>>
>>>
>>> Trying to get to a conclusion here,
>>> 3 different people said on this thread that they think that from
>>> the
>>> user perspective leaving the shared devices plugged is what they
>>> think
>>> is the best behavior to the user. (Omer, Kolesnik, Yair)
>>>
>>> On the other hand we have 2 people who think that protecting the
>>> user is
>>> more important than leaving the VM configuration as it was in the
>>> original VM (Miki, Ayal).
>>>
>>> Ayal/Miki can you please specify what are we protecting the user
>>> from?
>>>
>>>
>>> I think that because we are not snapshotting the shared disk and
>>> the
>>> direct LUN they should not be part of the VM configuration (in
>>> the
>>> snapshot) at all. we can not promise the user that the disk will
>>> be
>>> there and if it is there we can not guarantee it is in the same
>>> state as
>>> it was when we took the snapshot.
>>>
>>>
>>> Another issue,
>>>
>>> I can not see a reason to limit this feature to creating a VM
>>> from
>>> snapshot and not a template? Almost no extra work is needed for
>>> supporting templates as well.
>>
>> I assume you meant, creating a VM from another VM (if it is down)?
>> It should be supported.
>
> Actually I meant creating a Template from Snapshot.
Livnat - I think that in case of creating a template from snapshot we
should should have new API/Command, that will probably have lots in
common with Create VM from snapshot.
Why?
>
> What you suggested is creating a VM from VM.
> Although I see how the two are connected, I think they should be
> modeled
> as two different API calls.
> There is a difference in the flow, behavior, locks and parameters
> between the two.
>
> Behavior:
> - Original VM has to be down for creating a VM from VM, not the
> case for
> creating a VM from snapshot.
>
> parameters:
> - Creating VM from snapshot should support getting a snapshot-ID,
> Creating VM from VM get a VM id
>
> Locks:
> - When creating a VM from VM, we need to lock the original VM as a
> whole, we can not edit the VM, take snapshot or any other VM level
> action while such operation is active.
> While for creating the VM from snapshot we can take more
> fine-grained
> locks (only image related locks).
>
> Implementation:
> Well it is simply another implementation.
+1 on Livnat's explanation - I do see a (design/implementation wise)
an
option for some code reuse, but IMHO - this should be a new command
with
new API modelling
>
>
> Livnat
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
12:14 p.m.
----- Original Message -----
On 20/01/12 17:21, Itamar Heim wrote:
> On 01/20/2012 12:01 PM, Livnat Peer wrote:
>> On 20/01/12 09:35, Ayal Baron wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> Top Posting:
>>>>
>>>> From user POV I think that option 2 is the only one that make
>>>> sense.
>>>> We try to do as much as we can,
>>>> and on each "problematic" case, we make him aware and let him
>>>> decide.
>>>>
>>>
>>> Yep, +1.
>>>
>>
>> Trying to get to a conclusion here,
>> 3 different people said on this thread that they think that from
>> the
>> user perspective leaving the shared devices plugged is what they
>> think
>> is the best behavior to the user. (Omer, Kolesnik, Yair)
>>
>> On the other hand we have 2 people who think that protecting the
>> user is
>> more important than leaving the VM configuration as it was in the
>> original VM (Miki, Ayal).
>>
>> Ayal/Miki can you please specify what are we protecting the user
>> from?
>>
>>
>> I think that because we are not snapshotting the shared disk and
>> the
>> direct LUN they should not be part of the VM configuration (in the
>> snapshot) at all. we can not promise the user that the disk will
>> be
>> there and if it is there we can not guarantee it is in the same
>> state as
>> it was when we took the snapshot.
>>
>>
>> Another issue,
>>
>> I can not see a reason to limit this feature to creating a VM from
>> snapshot and not a template? Almost no extra work is needed for
>> supporting templates as well.
>
> I assume you meant, creating a VM from another VM (if it is down)?
> It should be supported.
Actually I meant creating a Template from Snapshot.
+1
What you suggested is creating a VM from VM.
Although I see how the two are connected, I think they should be
modeled
as two different API calls.
There is a difference in the flow, behavior, locks and parameters
between the two.
Behavior:
- Original VM has to be down for creating a VM from VM, not the case
for
creating a VM from snapshot.
parameters:
- Creating VM from snapshot should support getting a snapshot-ID,
Creating VM from VM get a VM id
What's the difference?
Locks:
- When creating a VM from VM, we need to lock the original VM as a
whole, we can not edit the VM, take snapshot or any other VM level
action while such operation is active.
While for creating the VM from snapshot we can take more fine-grained
locks (only image related locks).
I would suggest we change the clone VM flow to be:
1. create a snapshot in original VM
2. clone the snapshot
This way, while this is going on, the user *can* run the VM and do everything else and
behaviour becomes much nicer and not 'you have to wait 4 hours until your clone ends
before running the VM'.
3. delete the snapshot
This would also mean that both ops would be collapsed to one and there would be only 1
flow.
Implementation:
Well it is simply another implementation.
Livnat
1:12 p.m.
On 22/01/12 12:14, Ayal Baron wrote:
----- Original Message -----
> On 20/01/12 17:21, Itamar Heim wrote:
>> On 01/20/2012 12:01 PM, Livnat Peer wrote:
>>> On 20/01/12 09:35, Ayal Baron wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> Top Posting:
>>>>>
>>>>> From user POV I think that option 2 is the only one that make
>>>>> sense.
>>>>> We try to do as much as we can,
>>>>> and on each "problematic" case, we make him aware and let
him
>>>>> decide.
>>>>>
>>>>
>>>> Yep, +1.
>>>>
>>>
>>> Trying to get to a conclusion here,
>>> 3 different people said on this thread that they think that from
>>> the
>>> user perspective leaving the shared devices plugged is what they
>>> think
>>> is the best behavior to the user. (Omer, Kolesnik, Yair)
>>>
>>> On the other hand we have 2 people who think that protecting the
>>> user is
>>> more important than leaving the VM configuration as it was in the
>>> original VM (Miki, Ayal).
>>>
>>> Ayal/Miki can you please specify what are we protecting the user
>>> from?
>>>
>>>
>>> I think that because we are not snapshotting the shared disk and
>>> the
>>> direct LUN they should not be part of the VM configuration (in the
>>> snapshot) at all. we can not promise the user that the disk will
>>> be
>>> there and if it is there we can not guarantee it is in the same
>>> state as
>>> it was when we took the snapshot.
>>>
>>>
>>> Another issue,
>>>
>>> I can not see a reason to limit this feature to creating a VM from
>>> snapshot and not a template? Almost no extra work is needed for
>>> supporting templates as well.
>>
>> I assume you meant, creating a VM from another VM (if it is down)?
>> It should be supported.
>
> Actually I meant creating a Template from Snapshot.
+1
>
> What you suggested is creating a VM from VM.
> Although I see how the two are connected, I think they should be
> modeled
> as two different API calls.
> There is a difference in the flow, behavior, locks and parameters
> between the two.
>
> Behavior:
> - Original VM has to be down for creating a VM from VM, not the case
> for
> creating a VM from snapshot.
>
> parameters:
> - Creating VM from snapshot should support getting a snapshot-ID,
> Creating VM from VM get a VM id
What's the difference?
>
> Locks:
> - When creating a VM from VM, we need to lock the original VM as a
> whole, we can not edit the VM, take snapshot or any other VM level
> action while such operation is active.
> While for creating the VM from snapshot we can take more fine-grained
> locks (only image related locks).
I would suggest we change the clone VM flow to be:
1. create a snapshot in original VM
2. clone the snapshot
This way, while this is going on, the user *can* run the VM and do everything else and
behaviour becomes much nicer and not 'you have to wait 4 hours until your clone ends
before running the VM'.
3. delete the snapshot
This would also mean that both ops would be collapsed to one and there would be only 1
flow.
I am not sure this is the right way to support creating a VM from VM flow.
Let's say I have a server VM with RAW disks (for performance), I would
not want to take a snapshot from this VM to clone it.
>
> Implementation:
> Well it is simply another implementation.
>
>
> Livnat
>
>
3:21 p.m.
----- Original Message -----
On 22/01/12 12:14, Ayal Baron wrote:
>
>
> ----- Original Message -----
>> On 20/01/12 17:21, Itamar Heim wrote:
>>> On 01/20/2012 12:01 PM, Livnat Peer wrote:
>>>> On 20/01/12 09:35, Ayal Baron wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> Top Posting:
>>>>>>
>>>>>> From user POV I think that option 2 is the only one that make
>>>>>> sense.
>>>>>> We try to do as much as we can,
>>>>>> and on each "problematic" case, we make him aware and
let him
>>>>>> decide.
>>>>>>
>>>>>
>>>>> Yep, +1.
>>>>>
>>>>
>>>> Trying to get to a conclusion here,
>>>> 3 different people said on this thread that they think that from
>>>> the
>>>> user perspective leaving the shared devices plugged is what they
>>>> think
>>>> is the best behavior to the user. (Omer, Kolesnik, Yair)
>>>>
>>>> On the other hand we have 2 people who think that protecting the
>>>> user is
>>>> more important than leaving the VM configuration as it was in
>>>> the
>>>> original VM (Miki, Ayal).
>>>>
>>>> Ayal/Miki can you please specify what are we protecting the user
>>>> from?
>>>>
>>>>
>>>> I think that because we are not snapshotting the shared disk and
>>>> the
>>>> direct LUN they should not be part of the VM configuration (in
>>>> the
>>>> snapshot) at all. we can not promise the user that the disk will
>>>> be
>>>> there and if it is there we can not guarantee it is in the same
>>>> state as
>>>> it was when we took the snapshot.
>>>>
>>>>
>>>> Another issue,
>>>>
>>>> I can not see a reason to limit this feature to creating a VM
>>>> from
>>>> snapshot and not a template? Almost no extra work is needed for
>>>> supporting templates as well.
>>>
>>> I assume you meant, creating a VM from another VM (if it is
>>> down)?
>>> It should be supported.
>>
>> Actually I meant creating a Template from Snapshot.
>
> +1
>
>>
>> What you suggested is creating a VM from VM.
>> Although I see how the two are connected, I think they should be
>> modeled
>> as two different API calls.
>> There is a difference in the flow, behavior, locks and parameters
>> between the two.
>>
>> Behavior:
>> - Original VM has to be down for creating a VM from VM, not the
>> case
>> for
>> creating a VM from snapshot.
>>
>> parameters:
>> - Creating VM from snapshot should support getting a snapshot-ID,
>> Creating VM from VM get a VM id
>
> What's the difference?
>
>>
>> Locks:
>> - When creating a VM from VM, we need to lock the original VM as a
>> whole, we can not edit the VM, take snapshot or any other VM level
>> action while such operation is active.
>> While for creating the VM from snapshot we can take more
>> fine-grained
>> locks (only image related locks).
>
> I would suggest we change the clone VM flow to be:
> 1. create a snapshot in original VM
> 2. clone the snapshot
> This way, while this is going on, the user *can* run the VM and do
> everything else and behaviour becomes much nicer and not 'you have
> to wait 4 hours until your clone ends before running the VM'.
> 3. delete the snapshot
>
> This would also mean that both ops would be collapsed to one and
> there would be only 1 flow.
>
I am not sure this is the right way to support creating a VM from VM
flow.
Let's say I have a server VM with RAW disks (for performance), I
would
not want to take a snapshot from this VM to clone it.
There is only a performance problem if the VM is running.
Keeping as suggested before would prevent running the VM.
So what I'm suggesting is an improvement (when the VM is running it gives much better
performance compared to when it is not).
Then if the user ran the VM then there are 2 options at the end of the clone:
1. shutdown the VM and merge back (again, as opposed to not being able to run the VM - an
improvement)
2. live merge which would be costly but VM would go on running (also note that next
version will support merge in both directions so even better)
>>
>> Implementation:
>> Well it is simply another implementation.
>>
>>
>> Livnat
>>
>>
7:06 p.m.
On 22/01/12 15:21, Ayal Baron wrote:
----- Original Message -----
> On 22/01/12 12:14, Ayal Baron wrote:
>>
>>
>> ----- Original Message -----
>>> On 20/01/12 17:21, Itamar Heim wrote:
>>>> On 01/20/2012 12:01 PM, Livnat Peer wrote:
>>>>> On 20/01/12 09:35, Ayal Baron wrote:
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> Top Posting:
>>>>>>>
>>>>>>> From user POV I think that option 2 is the only one that
make
>>>>>>> sense.
>>>>>>> We try to do as much as we can,
>>>>>>> and on each "problematic" case, we make him aware
and let him
>>>>>>> decide.
>>>>>>>
>>>>>>
>>>>>> Yep, +1.
>>>>>>
>>>>>
>>>>> Trying to get to a conclusion here,
>>>>> 3 different people said on this thread that they think that from
>>>>> the
>>>>> user perspective leaving the shared devices plugged is what they
>>>>> think
>>>>> is the best behavior to the user. (Omer, Kolesnik, Yair)
>>>>>
>>>>> On the other hand we have 2 people who think that protecting the
>>>>> user is
>>>>> more important than leaving the VM configuration as it was in
>>>>> the
>>>>> original VM (Miki, Ayal).
>>>>>
>>>>> Ayal/Miki can you please specify what are we protecting the user
>>>>> from?
>>>>>
>>>>>
>>>>> I think that because we are not snapshotting the shared disk and
>>>>> the
>>>>> direct LUN they should not be part of the VM configuration (in
>>>>> the
>>>>> snapshot) at all. we can not promise the user that the disk will
>>>>> be
>>>>> there and if it is there we can not guarantee it is in the same
>>>>> state as
>>>>> it was when we took the snapshot.
>>>>>
>>>>>
>>>>> Another issue,
>>>>>
>>>>> I can not see a reason to limit this feature to creating a VM
>>>>> from
>>>>> snapshot and not a template? Almost no extra work is needed for
>>>>> supporting templates as well.
>>>>
>>>> I assume you meant, creating a VM from another VM (if it is
>>>> down)?
>>>> It should be supported.
>>>
>>> Actually I meant creating a Template from Snapshot.
>>
>> +1
>>
>>>
>>> What you suggested is creating a VM from VM.
>>> Although I see how the two are connected, I think they should be
>>> modeled
>>> as two different API calls.
>>> There is a difference in the flow, behavior, locks and parameters
>>> between the two.
>>>
>>> Behavior:
>>> - Original VM has to be down for creating a VM from VM, not the
>>> case
>>> for
>>> creating a VM from snapshot.
>>>
>>> parameters:
>>> - Creating VM from snapshot should support getting a snapshot-ID,
>>> Creating VM from VM get a VM id
>>
>> What's the difference?
>>
>>>
>>> Locks:
>>> - When creating a VM from VM, we need to lock the original VM as a
>>> whole, we can not edit the VM, take snapshot or any other VM level
>>> action while such operation is active.
>>> While for creating the VM from snapshot we can take more
>>> fine-grained
>>> locks (only image related locks).
>>
>> I would suggest we change the clone VM flow to be:
>> 1. create a snapshot in original VM
>> 2. clone the snapshot
>> This way, while this is going on, the user *can* run the VM and do
>> everything else and behaviour becomes much nicer and not 'you have
>> to wait 4 hours until your clone ends before running the VM'.
>> 3. delete the snapshot
>>
>> This would also mean that both ops would be collapsed to one and
>> there would be only 1 flow.
>>
>
> I am not sure this is the right way to support creating a VM from VM
> flow.
>
> Let's say I have a server VM with RAW disks (for performance), I
> would
> not want to take a snapshot from this VM to clone it.
There is only a performance problem if the VM is running.
Keeping as suggested before would prevent running the VM.
So what I'm suggesting is an improvement (when the VM is running it gives much better
performance compared to when it is not).
Then if the user ran the VM then there are 2 options at the end of the clone:
1. shutdown the VM and merge back (again, as opposed to not being able to run the VM - an
improvement)
2. live merge which would be costly but VM would go on running (also note that next
version will support merge in both directions so even better)
And what about quotas? with the above flow for cloning VM the user needs
quota on the source domain, I find this not intuitive for the user, and
i expect we'll have hard time explaining it.
>
>
>
>>>
>>> Implementation:
>>> Well it is simply another implementation.
>>>
>>>
>>> Livnat
>>>
>>>
>
>
5:09 p.m.
On 01/22/2012 09:26 AM, Livnat Peer wrote:
On 20/01/12 17:21, Itamar Heim wrote:
> On 01/20/2012 12:01 PM, Livnat Peer wrote:
>> On 20/01/12 09:35, Ayal Baron wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> Top Posting:
>>>>
>>>> From user POV I think that option 2 is the only one that make sense.
>>>> We try to do as much as we can,
>>>> and on each "problematic" case, we make him aware and let him
decide.
>>>>
>>>
>>> Yep, +1.
>>>
>>
>> Trying to get to a conclusion here,
>> 3 different people said on this thread that they think that from the
>> user perspective leaving the shared devices plugged is what they think
>> is the best behavior to the user. (Omer, Kolesnik, Yair)
>>
>> On the other hand we have 2 people who think that protecting the user is
>> more important than leaving the VM configuration as it was in the
>> original VM (Miki, Ayal).
>>
>> Ayal/Miki can you please specify what are we protecting the user from?
>>
>>
>> I think that because we are not snapshotting the shared disk and the
>> direct LUN they should not be part of the VM configuration (in the
>> snapshot) at all. we can not promise the user that the disk will be
>> there and if it is there we can not guarantee it is in the same state as
>> it was when we took the snapshot.
>>
>>
>> Another issue,
>>
>> I can not see a reason to limit this feature to creating a VM from
>> snapshot and not a template? Almost no extra work is needed for
>> supporting templates as well.
>
> I assume you meant, creating a VM from another VM (if it is down)?
> It should be supported.
Actually I meant creating a Template from Snapshot.
What you suggested is creating a VM from VM.
Although I see how the two are connected, I think they should be modeled
as two different API calls.
There is a difference in the flow, behavior, locks and parameters
between the two.
Behavior:
- Original VM has to be down for creating a VM from VM, not the case for
creating a VM from snapshot.
parameters:
- Creating VM from snapshot should support getting a snapshot-ID,
Creating VM from VM get a VM id
Locks:
- When creating a VM from VM, we need to lock the original VM as a
whole, we can not edit the VM, take snapshot or any other VM level
action while such operation is active.
While for creating the VM from snapshot we can take more fine-grained
locks (only image related locks).
Implementation:
Well it is simply another implementation.
These would be the "technical details", but from user perspective, I'd
argue cloning a snapshot is just cloning an older version of the VM.
i.e., i may pass to clone_vm an optional parameter to request cloning an
older version (specific snapshot), vs. cloning the latest down or
running VM.
for a running VM, ayal mentioned a possible flow (live snapshot, clone,
live merge).
implementing this doesn't have to be in same phase, but the question is
what is the right level of modeling for the API for the action.
7:01 p.m.
On 22/01/12 17:09, Itamar Heim wrote:
On 01/22/2012 09:26 AM, Livnat Peer wrote:
> On 20/01/12 17:21, Itamar Heim wrote:
>> On 01/20/2012 12:01 PM, Livnat Peer wrote:
>>> On 20/01/12 09:35, Ayal Baron wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> Top Posting:
>>>>>
>>>>> From user POV I think that option 2 is the only one that make
>>>>> sense.
>>>>> We try to do as much as we can,
>>>>> and on each "problematic" case, we make him aware and let
him decide.
>>>>>
>>>>
>>>> Yep, +1.
>>>>
>>>
>>> Trying to get to a conclusion here,
>>> 3 different people said on this thread that they think that from the
>>> user perspective leaving the shared devices plugged is what they think
>>> is the best behavior to the user. (Omer, Kolesnik, Yair)
>>>
>>> On the other hand we have 2 people who think that protecting the
>>> user is
>>> more important than leaving the VM configuration as it was in the
>>> original VM (Miki, Ayal).
>>>
>>> Ayal/Miki can you please specify what are we protecting the user from?
>>>
>>>
>>> I think that because we are not snapshotting the shared disk and the
>>> direct LUN they should not be part of the VM configuration (in the
>>> snapshot) at all. we can not promise the user that the disk will be
>>> there and if it is there we can not guarantee it is in the same
>>> state as
>>> it was when we took the snapshot.
>>>
>>>
>>> Another issue,
>>>
>>> I can not see a reason to limit this feature to creating a VM from
>>> snapshot and not a template? Almost no extra work is needed for
>>> supporting templates as well.
>>
>> I assume you meant, creating a VM from another VM (if it is down)?
>> It should be supported.
>
> Actually I meant creating a Template from Snapshot.
>
> What you suggested is creating a VM from VM.
> Although I see how the two are connected, I think they should be modeled
> as two different API calls.
> There is a difference in the flow, behavior, locks and parameters
> between the two.
>
> Behavior:
> - Original VM has to be down for creating a VM from VM, not the case for
> creating a VM from snapshot.
>
> parameters:
> - Creating VM from snapshot should support getting a snapshot-ID,
> Creating VM from VM get a VM id
>
> Locks:
> - When creating a VM from VM, we need to lock the original VM as a
> whole, we can not edit the VM, take snapshot or any other VM level
> action while such operation is active.
> While for creating the VM from snapshot we can take more fine-grained
> locks (only image related locks).
>
> Implementation:
> Well it is simply another implementation.
These would be the "technical details", but from user perspective, I'd
argue cloning a snapshot is just cloning an older version of the VM.
i.e., i may pass to clone_vm an optional parameter to request cloning an
older version (specific snapshot), vs. cloning the latest down or
running VM.
for a running VM, ayal mentioned a possible flow (live snapshot, clone,
live merge).
implementing this doesn't have to be in same phase, but the question is
what is the right level of modeling for the API for the action.
I agree that modeling the API should drive the decision here and not the
implementation.
I argue that because of the different behavior of the two actions we
should model it as two different operations.
If we force the VM to be down and we are locking the VM through out the
operation of cloning VM from VM while we don't have to do the above for
cloning VM from snapshot we should separate the two.
I think there are flaws with the flow Ayal suggested, I'll detailed them
in the context of his reply.
1:52 p.m.
On 01/19/2012 08:41 PM, Miki Kenneth wrote:
Top Posting:
From user POV I think that option 2 is the only one that make sense. We try to do as much
as we can,
and on each "problematic" case, we make him aware and let him decide.
Miki
Miki, just to clear /be sure - you're talking about taking the snapshot
as is, living the shared disk as "plugged" on destination VM?
Yair
----- Original Message -----
> From: "Ayal Baron" <abaron(a)redhat.com>
> To: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
> Cc: engine-devel(a)ovirt.org
> Sent: Thursday, January 19, 2012 4:04:02 AM
> Subject: Re: [Engine-devel] Question about CloneVMFromSnapshot feature in context of
shared disks and direct
> LUNs-based disks
>
>
>
> ----- Original Message -----
>> On 01/19/2012 10:32 AM, Mike Kolesnik wrote:
>>>
>>>
>>> ----- Original Message -----
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Livnat Peer" <lpeer(a)redhat.com>
>>>>> To: "Yair Zaslavsky" <yzaslavs(a)redhat.com>,
"Mike Kolesnik"
>>>>> <mkolesni(a)redhat.com>
>>>>> Cc: engine-devel(a)ovirt.org
>>>>> Sent: Thursday, January 19, 2012 9:19:52 AM
>>>>> Subject: Re: [Engine-devel] Question about CloneVMFromSnapshot
>>>>> feature in context of shared disks and direct
>>>>> LUNs-based disks
>>>>>
>>>>> On 19/01/12 08:38, Yair Zaslavsky wrote:
>>>>>> Hi all,
>>>>>> Following the upstream meeting dated Wednesday January 18th,
>>>>>> 2012
>>>>>> -
>>>>>> I presented the clone VM from snpashot feature and we
>>>>>> discussed
>>>>>> the
>>>>>> feature behaviour.
>>>>>>
>>>>>> Two issues that were raised are the behaviour of the feature
>>>>>> in
>>>>>> context
>>>>>> of shared disks and direct LUNs-based disks -
>>>>>> On one hand, if we copy&collapse such images - this may
yield
>>>>>> to
>>>>>> data
>>>>>> corruption (think of a scenario where the source and
>>>>>> destination
>>>>>> VMs use
>>>>>> the same disk).
>>>>>> On the other hand - if we decide not to copy&collapse - the
>>>>>> target
>>>>>> VM
>>>>>> will have missing VM and its state will not totally reflect
>>>>>> the
>>>>>> logical
>>>>>> state.
>>>>>> One of the solution raises is to mark such disks (at the
>>>>>> destination) as
>>>>>> unplugged, allowing the administrator the ability to plug them
>>>>>> (understanding of course the consequences).
>>>>>>
>>>>>> I would like to receive inputs on this issue
>>>>>>
>>>>>>
>>>>>> Kind regards,
>>>>>>
>>>>>> Yair
>>>>>
>>>>> Hi Yair,
>>>>>
>>>>> Some clarifications on the above issue.
>>>>> Currently when taking a snapshot on a VM with shared disks or
>>>>> direct
>>>>> LUN
>>>>> disk there are 3 optional behaviors:
>>>>>
>>>>> 1. Blocking the snapshot action. (User can not take a snapshot
>>>>> of
>>>>> the
>>>>> VM
>>>>> if it has plugged shared or direct LUN disks)
>>>>>
>>>>> 2. Taking the snapshot and marking the shared disk and direct
>>>>> LUN
>>>>> disks
>>>>> as unplugged (in the VM snapshot configuration) and marking the
>>>>> snapshot
>>>>> state as partial.
>>>>>
>>>>> 3. Taking the snapshot of the VM as is, leaving the VM
>>>>> configuration
>>>>> with plugged disks.
>>>>>
>>>>>
>>>>> The issue with including these disks in the snapshot is that
>>>>> they
>>>>> are
>>>>> not really being snapshotted, they are not capturing the point
>>>>> in
>>>>> time
>>>>> we are trying to achieve in the snapshot.
>>>>>
>>>>> Enabling the snapshot action in such a state is a bit
>>>>> misleading
>>>>> to
>>>>> the
>>>>> user.
>>>>>
>>>>> If we do allow taking the snapshot we should mark the snapshot
>>>>> as
>>>>> partial to indicate that the snapshot did not capture the point
>>>>> in
>>>>> time
>>>>> as the user intended.
>>>>>
>>>>> I have no preference with regards to the second and third
>>>>> approach,
>>>>> the
>>>>> second approach is a bit more safe, we basically force the user
>>>>> to
>>>>> plug
>>>>> the disks and be sure that he knows what he is doing and the
>>>>> third
>>>>> approach is less safe and less annoying to the user (he took
>>>>> the
>>>>> snapshot, cloned it and wants to start the VM - don't require
>>>>> extra
>>>>> actions)
>>>>>
>>>>> Kolesnik - please note when starting VM in a preview mode we
>>>>> should
>>>>> mount the disks in read-only mode (if supported).
>>>
>>> I don't understand this, can you please elaborate why and in
>>> which
>>> case?
>>> The disk is plugged/unplugged?
>>> What happens when you commit? It becomes r/w?
>>>
>>>>>
>>>>>
>>>>> Livnat
>>>>>
>>>>>
>>>>>
>>>>
>>>> +1 for option 3
>>>>
>>>
>>> +1 for option 3 as well (also good with option 1, but I think
>>> this
>>> will hinder usability).
>> I agree with Mike - I think option one is too "aggressive" in
>> protecting
>> us, this is why I prefer 3. +1 on option 3
>
> This would only be acceptable if the disk is marked read only.
> Just leaving the disk plugged means many users *will* corrupt their
> VMs.
> That trumps the need to mark a checkbox if you want it available.
>
> As I said before, readonly has its own problems and in fact, IMO the
> behaviour is even more difficult to explain (yeah, you might corrupt
> the running VM if it's r/w so we made it r/o and now if you start up
> your clone / preview you will get a kernel panic).
>
>>>
>>>
>>> Regards,
>>> Mike
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
11:53 a.m.
On 01/19/2012 09:19 AM, Livnat Peer wrote:
On 19/01/12 08:38, Yair Zaslavsky wrote:
> Hi all,
> Following the upstream meeting dated Wednesday January 18th, 2012 -
> I presented the clone VM from snpashot feature and we discussed the
> feature behaviour.
>
> Two issues that were raised are the behaviour of the feature in context
> of shared disks and direct LUNs-based disks -
> On one hand, if we copy&collapse such images - this may yield to data
> corruption (think of a scenario where the source and destination VMs use
> the same disk).
> On the other hand - if we decide not to copy&collapse - the target VM
> will have missing VM and its state will not totally reflect the logical
> state.
> One of the solution raises is to mark such disks (at the destination) as
> unplugged, allowing the administrator the ability to plug them
> (understanding of course the consequences).
>
> I would like to receive inputs on this issue
>
>
> Kind regards,
>
> Yair
Hi Yair,
Some clarifications on the above issue.
Currently when taking a snapshot on a VM with shared disks or direct LUN
disk there are 3 optional behaviors:
1. Blocking the snapshot action. (User can not take a snapshot of the VM
if it has plugged shared or direct LUN disks)
2. Taking the snapshot and marking the shared disk and direct LUN disks
as unplugged (in the VM snapshot configuration) and marking the snapshot
state as partial.
just making sure - this wouldn't change the active running config (when
taking a live snapshot)?
doesn't it mean we could take partial snapshot for any type of disks
then (internal ones as well)?
12:03 p.m.
----- Original Message -----
On 01/19/2012 09:19 AM, Livnat Peer wrote:
> On 19/01/12 08:38, Yair Zaslavsky wrote:
>> Hi all,
>> Following the upstream meeting dated Wednesday January 18th, 2012
>> -
>> I presented the clone VM from snpashot feature and we discussed
>> the
>> feature behaviour.
>>
>> Two issues that were raised are the behaviour of the feature in
>> context
>> of shared disks and direct LUNs-based disks -
>> On one hand, if we copy&collapse such images - this may yield to
>> data
>> corruption (think of a scenario where the source and destination
>> VMs use
>> the same disk).
>> On the other hand - if we decide not to copy&collapse - the
>> target VM
>> will have missing VM and its state will not totally reflect the
>> logical
>> state.
>> One of the solution raises is to mark such disks (at the
>> destination) as
>> unplugged, allowing the administrator the ability to plug them
>> (understanding of course the consequences).
>>
>> I would like to receive inputs on this issue
>>
>>
>> Kind regards,
>>
>> Yair
>
> Hi Yair,
>
> Some clarifications on the above issue.
> Currently when taking a snapshot on a VM with shared disks or
> direct LUN
> disk there are 3 optional behaviors:
>
> 1. Blocking the snapshot action. (User can not take a snapshot of
> the VM
> if it has plugged shared or direct LUN disks)
>
> 2. Taking the snapshot and marking the shared disk and direct LUN
> disks
> as unplugged (in the VM snapshot configuration) and marking the
> snapshot
> state as partial.
just making sure - this wouldn't change the active running config
(when
taking a live snapshot)?
no, only the config of the snapshot.
doesn't it mean we could take partial snapshot for any type of
disks
then (internal ones as well)?
To do this properly you would need to drive it from the GUI. Currently the behaviour was
defined as implicit (engine would automatically do this according to disk type).
In any event, even if partial snapshots will not be available in 3.1, the API should get
the list of LUNs to snapshot and just raise an error if not all devices were passed.
Otherwise we'd need a new API for partial snapshots (I'm talking about REST API in
case this isn't clear).
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
1:45 p.m.
On 19/01/12 12:03, Ayal Baron wrote:
----- Original Message -----
> On 01/19/2012 09:19 AM, Livnat Peer wrote:
>> On 19/01/12 08:38, Yair Zaslavsky wrote:
>>> Hi all,
>>> Following the upstream meeting dated Wednesday January 18th, 2012
>>> -
>>> I presented the clone VM from snpashot feature and we discussed
>>> the
>>> feature behaviour.
>>>
>>> Two issues that were raised are the behaviour of the feature in
>>> context
>>> of shared disks and direct LUNs-based disks -
>>> On one hand, if we copy&collapse such images - this may yield to
>>> data
>>> corruption (think of a scenario where the source and destination
>>> VMs use
>>> the same disk).
>>> On the other hand - if we decide not to copy&collapse - the
>>> target VM
>>> will have missing VM and its state will not totally reflect the
>>> logical
>>> state.
>>> One of the solution raises is to mark such disks (at the
>>> destination) as
>>> unplugged, allowing the administrator the ability to plug them
>>> (understanding of course the consequences).
>>>
>>> I would like to receive inputs on this issue
>>>
>>>
>>> Kind regards,
>>>
>>> Yair
>>
>> Hi Yair,
>>
>> Some clarifications on the above issue.
>> Currently when taking a snapshot on a VM with shared disks or
>> direct LUN
>> disk there are 3 optional behaviors:
>>
>> 1. Blocking the snapshot action. (User can not take a snapshot of
>> the VM
>> if it has plugged shared or direct LUN disks)
>>
>> 2. Taking the snapshot and marking the shared disk and direct LUN
>> disks
>> as unplugged (in the VM snapshot configuration) and marking the
>> snapshot
>> state as partial.
>
> just making sure - this wouldn't change the active running config
> (when
> taking a live snapshot)?
no, only the config of the snapshot.
> doesn't it mean we could take partial snapshot for any type of disks
> then (internal ones as well)?
Not in this version, we added the concept of partial snapshot to enable
deleting a disk from a VM with snapshots. We mark all snapshots that
used this disk as partial.
To do this properly you would need to drive it from the GUI. Currently the behaviour was
defined as implicit (engine would automatically do this according to disk type).
In any event, even if partial snapshots will not be available in 3.1, the API should get
the list of LUNs to snapshot and just raise an error if not all devices were passed.
Otherwise we'd need a new API for partial snapshots (I'm talking about REST API
in case this isn't clear).
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
4689
days inactive
4692
days old
26 comments
7 participants
participants (7)
-
Ayal Baron -
Itamar Heim -
Livnat Peer -
Mike Kolesnik -
Miki Kenneth -
Omer Frenkel -
Yair Zaslavsky