Re: [Engine-devel] VM disks

2012-02-18 Thread Oved Ourfalli


- Original Message -
 From: Livnat Peer lp...@redhat.com
 To: engine-devel@ovirt.org
 Sent: Saturday, February 18, 2012 7:07:01 PM
 Subject: [Engine-devel] VM disks
 
 Hi,
 
 These days we are working on various features around VM disks, in the
 different threads it was decided that we'll have the ability to
 attach a
 disk to a VM but it will be added as inactive, then the user can
 activate it for it to be accessible from within the guest.
 
 Flow of adding a new disk would be:
 - creating the disk
 - attaching the disk to the VM
 - activating it
 
 Flow of adding a shared disk (or any other existing disk):
 - attach the disk
 - activate it
 
 It seems to me a lot like adding a storage domain and I remember a
 lot
 of rejections on the storage domain flow (mostly about it being too
 cumbersome).
 After discussing the issue with various people we could not find a
 good
 reason for having a VM disk in attached but inactive mode.
 
 Of course we can wrap the above steps in one step for specific flows
 (add+attach within a VM context for example) but can anyone think on
 a
 good reason to support attached but inactive disk?
 
 I would suggest that when attaching a disk to a VM it becomes part of
 the VM (active) like in 'real' machines.
 
+1 on that (regardless of whether the disk is shared or not).
IMO - in the case of shared disk we should make it as clear as possible to the 
user/admin that the added disk is shared, but the flow should be exactly the 
same.


 
 Thank you, 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


Re: [Engine-devel] VM disks

2012-02-18 Thread Michael Kublin


- Original Message -
 From: Oved Ourfalli ov...@redhat.com
 To: Livnat Peer lp...@redhat.com
 Cc: engine-devel@ovirt.org
 Sent: Sunday, February 19, 2012 9:48:31 AM
 Subject: Re: [Engine-devel] VM disks
 
 
 
 - Original Message -
  From: Livnat Peer lp...@redhat.com
  To: engine-devel@ovirt.org
  Sent: Saturday, February 18, 2012 7:07:01 PM
  Subject: [Engine-devel] VM disks
  
  Hi,
  
  These days we are working on various features around VM disks, in
  the
  different threads it was decided that we'll have the ability to
  attach a
  disk to a VM but it will be added as inactive, then the user can
  activate it for it to be accessible from within the guest.
  
  Flow of adding a new disk would be:
  - creating the disk
  - attaching the disk to the VM
  - activating it
These should be in a one step, otherwise the clients (rest and gui) will need 
to pool us 
for every disk 
  Flow of adding a shared disk (or any other existing disk):
  - attach the disk
  - activate it
These is just simple as a hot plug , should be and it is easy implement as one 
step
  It seems to me a lot like adding a storage domain and I remember a
  lot
  of rejections on the storage domain flow (mostly about it being too
  cumbersome).
  After discussing the issue with various people we could not find a
  good
  reason for having a VM disk in attached but inactive mode.
  
  Of course we can wrap the above steps in one step for specific
  flows
Agreed, should be in one step
  (add+attach within a VM context for example) but can anyone think
  on
  a
  good reason to support attached but inactive disk?
I don't see a reason also.

  I would suggest that when attaching a disk to a VM it becomes part
  of
  the VM (active) like in 'real' machines.
  
 +1 on that (regardless of whether the disk is shared or not).
 IMO - in the case of shared disk we should make it as clear as
 possible to the user/admin that the added disk is shared, but the
 flow should be exactly the same.
Also agreed
 
  
  Thank you, 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
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel