[Engine-devel] SharedRawDisk feature detail

[Oved Ourfalli]

----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Maor" <mlipchuk at redhat.com>
> Cc: engine-devel at ovirt.org, "Haim Ateya" <hateya at redhat.com>
> Sent: Monday, February 13, 2012 9:17:41 AM
> Subject: Re: [Engine-devel] SharedRawDisk feature detail
> 
> On 13/02/12 00:06, Ayal Baron wrote:
> > I started writing the changes in the email but got tired of it and
> > just made a bunch of changes in the wiki (impossible to track in
> > email, such things should be done using etherpad or something).
> > 
> > A few questions though:
> > 
> > plugged vs. enabled - I thought we converged on attached/detached
> > and enabled/disabled and not plugged/unplugged?
> > 
> > * Shared disks are attached with R/W permissions.
> > - What about enabling R/O ? (esp. for stateless/pools)
> > 
> 
> Do we have ack from libvirt that attaching disk in r/o mode actually
> works? (I know we opened a bug for testing this but i can't find the
> bug
> - Haim?)
> 
> > 
> > * Template disks should not be shared.
> > - Why not? (read only)
> > 
> > * When exporting a VM, only the disks which are not shared will be
> > exported.
> > - Why is the above not treated the same as a snapshot? the
> > configuration will reference the shared disk as unplugged? (or
> > will it and it's just not clear?)
> > 
> 
> It is not the same case as snapshot. We don't have in the export
> domain
> the shared image.
> 
> > I didn't touch stateless/pools but should be fixed to reflect
> > comments on this thread.
> > 
> > Is Remove shared disk and Delete shared disk the same thing? if so,
> > why the dual terminology?
> > I don't quite follow the logic determining which section is under
> > functionality and which under user experience.  For example, why
> > do you have a 'Delete shared disk' section in the Ux section but
> > not a 'Move shared disk' section (there is no shared disk specific
> > logic visible in the delete action UI).
> > 
> > 
> > * Disk name should be generated automatically based on the vm name
> > and disk number in the VM. Description will be empty.
> > * New disk should enforce the user to enter a name for the disk.
> > - Huh? the above 2 items seem like an oxymoron, but I may be
> > missing something...
> > 
> 
> The first line is referring to upgrade flow (it is under the upgrade
> section), the second line is the behavior going forward.
> 
> I agree this is confusing, Maor I suggest you remove the general
> behavior from the upgrade section.
> 
> 
> > * Attach/Detach of a shared disk can be performed only when the VM
> > is in status 'down'.
> > - Why? under the functionality section you clearly stated that
> > attaching a disk will result in it being attached but disabled...
> > 
> > 
> 
> I agree with Ayal on this.
> Attach/Detach a disk should be enabled regardless if the VM is
> running
> or not, this applies to all disks not only to shared disk.
> 
> Maor, few more questions:
> 
> * "Regular disk can become a shared raw disk, by editing the existing
> disk and marking the 'share disk' property type."
> 
> There are limitation to this, for example disk with snapshots can not
> be
> shared (we support only shared raw disks etc.)
> 
> 
> * "When removing a VM with shared disks attached to it, the shared
> disks
> will not be deleted. "
> 
> If the shared disk is not attached to any other VM, why don't we
> delete it?
> I think we should behave with it as any other disk.
> Maybe going forward when deleting a VM we should ask if to remove the
> disks as well. This logic can apply to shared disk in the same way, I
> don't think we should have a special logic around this for shared
> disks.
> 
Do we plan to support deleting disks in the disks tab? (as part of supporting floating disks)
If not then we should delete the disk (as we won't be able to delete it after the last VM using it is deleted....).
If we do, then I think we should indeed ask the user whether he would like to delete those disks or not (in case it is the last VM).
Deleting it implicitly might be wrong, as these disks might contain data that the user would like to attach to a new VM.

> 
> * The VDSM owner  is missing from the doc, and vdsm is missing from
> the
> affected projects.
> 
> 
> Livnat
> 
> > 
> > ----- Original Message -----
> >> On 02/02/12 17:15, Maor wrote:
> >>> Hello all,
> >>>
> >>> The shared raw disk feature description can be found under the
> >>> following
> >>> links:
> >>>   http://www.ovirt.org/wiki/Features/DetailedSharedRawDisk
> >>>   http://www.ovirt.org/wiki/Features/SharedRawDisk
> >>>
> >>> Please feel free, to share your comments.
> >>>
> >>> Regards,
> >>> Maor
> >>> _______________________________________________
> >>> Engine-devel mailing list
> >>> Engine-devel at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> >> Hi Maor,
> >>
> >> - "when taking a VM snapshot, a snapshot of the shared disk will
> >> not
> >> be
> >> taken."
> >> I think it is worth mentioning that the shared disk will be part
> >> of
> >> the
> >> VM snapshot configuration. The disk will appear as unplugged.
> >>
> >> - Move VM is deprecated in 3.1.
> >>
> >> - It seems from the wiki that shared disk is not supported for
> >> template
> >> but is supported for VM pool.
> >> I am not sure how can we do that? iirc we create pool from
> >> template.
> >>
> >> What is the complexity of supporting shared disk in Templates? off
> >> the
> >> top of my head it seems like it is more complicated to block
> >> shared
> >> disks in templates than to support it. What do you think?
> >>
> >>
> >> Livnat
> >>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>