- What is the nature and description of the request?
Customer needs a way to be able to determine how long a user has been attached to a VM in a pool. The VMs are all pre-started, so there's no easy way to tell.
- Why does the customer need this? (List the business requirements here)
The purpose is to be able to manually shut down unused idle VMs that have been abandoned for a certain amount of time.
Previous bugzillas have been filed that are relevant here:
- 877207 ([RFE] allow VMs to be shut down automatically according to business rules). This bugzilla, if implemented, would automatically shut down the VMs under certain conditions. This is slightly different, in that this particular request is basically information-only, so that the VMs could be powered down manually.
- 879586 ([RFE] Display and keep track of both the client user and the in-guest session username). This bugzilla is closed-errata, and should make this easier to implement
- 883855 (Use guest agent to report logged in users) was closed as a duplicate of 879586
users attached to pool using permission.
to view the duration a VM is attached to a user I'm going to nhance permissions table with creation date (seconds from epoch)
admins can inpect the permission subtab of a pool and see a new column added there with the date and duration
User | Auth provider | Namespace | Role | Creation Date | Inherited |
Roy | internal | * | UserRole | 22/11/2014 (45 days ago) |
to see how much time user(s) attached to vm you need to see this in the permissions sub tab of the vm, not the pool.
(permissions on pool is the users that can use it, permissions on the vm are the user(s) that are using the specific vm currently)
(In reply to Roy Golan from comment #3)
> users attached to pool using permission.
> to view the duration a VM is attached to a user I'm going to nhance
> permissions table with creation date (seconds from epoch)
> admins can inpect the permission subtab of a pool and see a new column added
> there with the date and duration
> something like
> User | Auth provider | Namespace | Role | Creation Date |
> Inherited |
> Roy | internal | * | UserRole | 22/11/2014 (45 days ago) |
I didn't implement the "(45 days ago)" addition. just left the creation date as is.
The implementation of RFE looks wrong in my opinion.
The customer wanted to know how long a user has been attached to a VM in a pool.
In order to be able to manually shut down unused idle VMs.
The implementation here is to add the permission creation date, you can't really know from the permission creation date if the vm's aren't being used.
Moving to PM to additional info.
(In reply to Shira Maximov from comment #6)
> The implementation of RFE looks wrong in my opinion.
> The customer wanted to know how long a user has been attached to a VM in a
> In order to be able to manually shut down unused idle VMs.
> The implementation here is to add the permission creation date, you can't
> really know from the permission creation date if the vm's aren't being used.
we can't really know if vm is "being used", what exactly does it mean?
the permission create date is the date the user was attached to the vm,
so you can know how long the user is attached to the vm, and make decision according to this, which is exactly what was requested here.
what info are you missing?
In my opinion you can really tell from the permission creation date if it's ok to shut down a VM.
lets say that i have 10 VMs that i started two months ago, those VMs uses a lot resources but I didn't use those VMs during this period of time at all.
Do you think that in this case the permission creation date can help me?
don't forget we are talking about vm-pool.
so if your use case is that users usually take vms, use it for a week, and then return it (lets say you are running a 1-week course cycles in some university), but here you notice vm that is assigned to a user for 2 months (looking at the permission date), then its suspicious/irregular and you need to investigate with the user of this vm what is going on and act..
this was (for my understanding) the nature of the request here, and not about cpu/memory/network/storage/.. usage.
would you please take a look at comments #6-9?
Is the implementation seem OK, or mismatch the customer needs?
Following a conversation, I understand the following about this RFE and proposed solution:
* We are tracking when a user is assigned a VM from the pool based on the timestamp of when the permission was assigned to the user.
* If a user disconnects from the VM and no longer needs the session, the VM is powered off, and has no permissions assigned in that state
* The only way it is possible to have Powered On VMs without a user permission is from the pre-configured Powered On VMs pool, which are explicitly configured by the user
* The only thing we can tell the user effectively is that: "User foo was assigned to VM bar 45 days ago".
* The end user will need to determine a trigger based on the available data as to what normal/abnormal behavior is. (ie: User foo has been logged in to VM bar for 45 days, that seems like a REALLY long time. I need to check if VM bar is still actively in use.
Omer/Ilanit, please verify I do not misunderstand current status/design?
sounds right to me.
just a little note, to be 100% accurate, another option to have a pool-vm up and not assigned to a user, beside setting the 'pre-started' is if the administrator manually start it from the web-admin (in contrary to users that "take" pool-vms in the user-portal)
We've (me & Shira) discussed with Omer, and we understand the limitation of not being able to actually determine how many days a user has been attached to a pooled VM,
Displaying the information of when permissions were given to a user, seems the best effort that can be done here.
Correction to comment #13:
limitation of not being able to actually determine how many days a user has been attached to a pooled VM
limitation of not being able to actually determine how many days a user has been using a pooled VM
verify on the following version:
Red Hat Enterprise Virtualization Manager Version: 18.104.22.168-0.1.el6
link to test run: https://polarion.engineering.redhat.com/polarion/#/project/RHEVM3/testruns
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.