[Engine-devel] Question about CloneVMFromSnapshot feature in context of shared disks and direct LUNs-based disks
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
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
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com>, "Mike Kolesnik" <mkolesni@redhat.com> Cc: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
+1 for option 3
----- Original Message -----
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com>, "Mike Kolesnik" <mkolesni@redhat.com> Cc: engine-devel@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
----- Original Message -----
----- Original Message -----
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com>, "Mike Kolesnik" <mkolesni@redhat.com> Cc: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 01/19/2012 10:32 AM, Mike Kolesnik wrote:
----- Original Message -----
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com>, "Mike Kolesnik" <mkolesni@redhat.com> Cc: engine-devel@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
----- Original Message -----
On 01/19/2012 10:32 AM, Mike Kolesnik wrote:
----- Original Message -----
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com>, "Mike Kolesnik" <mkolesni@redhat.com> Cc: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: engine-devel@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@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com>, "Mike Kolesnik" <mkolesni@redhat.com> Cc: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- 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@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: engine-devel@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@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com>, "Mike Kolesnik" <mkolesni@redhat.com> Cc: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: engine-devel@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@redhat.com> > To: "Yair Zaslavsky" <yzaslavs@redhat.com>, "Mike Kolesnik" > <mkolesni@redhat.com> > Cc: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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.
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@redhat.com> To: "Livnat Peer" <lpeer@redhat.com> Cc: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- 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@redhat.com> To: "Livnat Peer" <lpeer@redhat.com> Cc: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Ayal Baron" <abaron@redhat.com> To: "Miki Kenneth" <mkenneth@redhat.com> Cc: engine-devel@ovirt.org, "Itamar Heim" <iheim@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@redhat.com> To: "Livnat Peer" <lpeer@redhat.com> Cc: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- 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
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
----- 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
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
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.
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.
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@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: engine-devel@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@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com>, "Mike Kolesnik" <mkolesni@redhat.com> Cc: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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)?
----- 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
participants (7)
-
Ayal Baron -
Itamar Heim -
Livnat Peer -
Mike Kolesnik -
Miki Kenneth -
Omer Frenkel -
Yair Zaslavsky