Bug 834839

Summary:	pre started vms in pool - can't set when creating the pool
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Itamar Heim <iheim>
Component:	ovirt-engine	Assignee:	Tomas Jelinek <tjelinek>
Status:	CLOSED DUPLICATE	QA Contact:	Tomas Dosek <tdosek>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	abaron, bazulay, dyasny, ecohen, hateya, iheim, lpeer, michal.skrivanek, msalem, Rhev-m-bugs, tdosek, yeylon, ykaul
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	virt
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-08-28 11:39:56 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Itamar Heim 2012-06-24 07:10:23 UTC

appearntly it is complicated to set this during pool creation.
we can live with that for now, but the field should still appear on the 'new pool dialog' in grayed out with a tooltip explaining it can be set when the pool is created.

Comment 1 Itamar Heim 2012-06-24 07:11:04 UTC

note i'm not sure how the race between pre-strted vms for pool creation is different from when extending the pool, so maybe we do just need to fix it.

Comment 2 Itamar Heim 2012-06-28 16:44:56 UTC

muli - can you please elaborate on the reasoning for this limitation per my comment 1?

Comment 3 Itamar Heim 2012-06-28 21:33:54 UTC

related to bug 835000 as well (which just tracks the UI layout)

Comment 4 Muli Salem 2012-07-11 07:01:19 UTC

(In reply to comment #1)
> note i'm not sure how the race between pre-strted vms for pool creation is
> different from when extending the pool, so maybe we do just need to fix it.

True. The same problem arises when we extend a pool, since we don't want the new vms to be part of the prestarted batch, until the administrator says so. This is due to cases such as the need to sysprep the vm by the admin, before prestarting. Possible solutions include adding a new parameter per pool, that indicates whether prestarting is currently enabled.

Comment 5 Itamar Heim 2012-08-01 12:48:34 UTC

*** Bug 844913 has been marked as a duplicate of this bug. ***

Comment 6 Tomas Jelinek 2012-08-13 06:16:31 UTC

> but the field should still appear on the 'new pool dialog' in grayed out with a > tooltip explaining it can be set when the pool is created.
Could someone please provide the exact phrasing of this tooltip message?

Comment 7 Michal Skrivanek 2012-08-14 10:57:21 UTC

(In reply to comment #6)
> > but the field should still appear on the 'new pool dialog' in grayed out with a > tooltip explaining it can be set when the pool is created.
> Could someone please provide the exact phrasing of this tooltip message?

I would go with: Prestarted VMs can only be edited once the pool is created

Comment 8 Tomas Jelinek 2012-08-14 12:53:48 UTC

in gerrit: http://gerrit.ovirt.org/#/c/7173/

Comment 9 Ayal Baron 2012-08-14 15:58:25 UTC

(In reply to comment #4)
> (In reply to comment #1)
> > note i'm not sure how the race between pre-strted vms for pool creation is
> > different from when extending the pool, so maybe we do just need to fix it.
> 
> True. The same problem arises when we extend a pool, since we don't want the
> new vms to be part of the prestarted batch, until the administrator says so.
> This is due to cases such as the need to sysprep the vm by the admin, before
> prestarting. Possible solutions include adding a new parameter per pool,
> that indicates whether prestarting is currently enabled.

I created a pool and then immediately edited it and changed pre-started without syspreping, so the above exists regardless and hence not a good reason to block user from setting it in create flow.

If user wants to first sysprep then when creating the pool he won't set anything to prestarted.

I also don't see the big deal in the VM being started and then admin restarting it with the sysprep disk attached.

Comment 10 Itamar Heim 2012-08-15 10:35:36 UTC

isn't the patch for this and bug 835000 solving it the same way (gui only change for now. release note on behavior implications i guess?)
close on as duplicate or move this one to future to allow this setting?

Comment 11 Michal Skrivanek 2012-08-15 10:42:16 UTC

well, Ayal disagreed with my rhevm_future in 835000.
Otherwise it is indeed about the same thing. The GUI change is not that radical as the vcpu editing so maybe its not too late to change it. Ill discuss with Tomas and if were going to proceed with 835000 now we can abandon this one

Comment 12 Michal Skrivanek 2012-08-28 11:39:56 UTC

dupe to 835000 as it solves this issue

*** This bug has been marked as a duplicate of bug 835000 ***