VMware Horizon Community
MG1971
Contributor
Contributor

AppVolumes 4.2 (2009) can´t delete unassigned package

Hello everybody,

I have an issue to delete a Package in AppVolume 4.2. The delete button is gray.

delete_package.png

 

 

Reply
0 Kudos
20 Replies
Ray_handels
Virtuoso
Virtuoso

Yep, your answer is in the screenshot 🙂 :).

Look at attachments, it says 1. No idea where it is attached to but you cannot remove a package if it is still attached to a machine.

make sure to unattach it (if you assigned it, make sure the user that had the attachments logs out) and then you will see that you can remove it.

Reply
0 Kudos
bw-man
Contributor
Contributor

and what is if this attachment is not visible in attachments ?

You can not unattach what you can not see.

And then ?

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso

If it still sees it as attached it could be that the database is not yet cleaned and thus still thinks it is attached. 

What happens if you go to the attachment tab? Or could it be that it is still attached to a package machine maybe?

Reply
0 Kudos
MG1971
Contributor
Contributor

It´s not attached to any machine. The packaging machines are offline.

Reply
0 Kudos
pieterheijms
Enthusiast
Enthusiast

How did you solve this problem?

We have the same issue.

Reply
0 Kudos
Markus_Gundelac
Contributor
Contributor

Is not resolved until now

Reply
0 Kudos
pieterheijms
Enthusiast
Enthusiast

Thanks

Reply
0 Kudos
scythe944
Contributor
Contributor

I'm having the same problem with an Adobe acrobat package.  It's not assigned to anyone, I see no attachments, but the system still thinks that there's something attached and doesn't let me delete it.  Any pointers on how to clear the "attachment" so I can delete this old package?

Reply
0 Kudos
Micheal_A
VMware Employee
VMware Employee

If the package is locked by a system that no-longer exists, you will have to put a support request in to have GSS run some ruby rails console commands to delete the package for you.

I would not try this your self, because this could corrupt your AppVol database.

 

 

VMware EUC by Broadcom
https://techzone.vmware.com/
Reply
0 Kudos
Lieven
Hot Shot
Hot Shot

I had the same issue.

I solved it by doing the following:

1. creating a new Application. (I named it TO_DELETE)

2. Moved the application I could not delete to this new application TO_DELETE

3. Wait 1 day

4. Deleted the application TO_DELETE together with the package it contained

 

Version I am using is App Volumes 4.5 (2111.1)

scythe944
Contributor
Contributor

Funny thing then, VMware support has had my case for about 3-4 weeks and just responded a few days ago that updating to app volumes 2111 would resolve the issue.  It appears that you're using this version and still need to wrangle with a fix.  I was hoping to upgrade our appvolumes servers this weekend when no one was using them to see if it worked.

thanks for your suggestions, Lieven

Reply
0 Kudos
Micheal_A
VMware Employee
VMware Employee

I would suggest, if you still are having the deletion issue, to have GSS run the Ruby Rails commands to delete this package. this will confirm that all traces of the this package will be deleted from the database.

@Lievenworkaround is not supported by GSS and we cannot confirm if there is still a possible bug that needs to be repo'd.

I work closely with the AppVolumes VMware engineering team and they want to know of these problems ASAP.

VMware EUC by Broadcom
https://techzone.vmware.com/
Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso

Hey @Micheal_A that's strange because we have the exact same issue and they are stating that it is being checked by by engineering.

I do have another workaround which is not supported, at least that's my guess. Will point out here that I am not a VMware employee and use at your own risk :).

When you run a select * from snapvols command towards the database there is a column there that is called Attachment_count, this holds the info if a snapvol is indeed attached. If you manually change that to 0 you are able to remove the application and it will remove the packages as well.

As a cross check I would also make sure to also use the following 

select * from snapvol_attachment where snaopvol_id = <ID of the snapvol>. This should not return any results, otherwise it actually does have an attachment towards some machine but at least you'll know which one it is.

But to me this seems to be a bug in how Appvolumes registrates the attachments in the database. It should normally run a check for every snapvol (which actually is a package) if it still has attachments in the snapvol_attachments table.

aflopez
Contributor
Contributor

We upgraded to 2111 and the issue still persists. I opened a ticket after the upgrade and haven't received any traction on a fix for the issue.

NLAVOIE
Contributor
Contributor

This worked for us. Thanks.

Reply
0 Kudos
hermanc01
Enthusiast
Enthusiast

I've been having this same issue in our environment as well.  If you run Rescan under Inventory > Applications, it should detect that the attachments are gone and will allow you delete the packages.  I thought there is a background job that's supposed to clear these but I guess it's broken.

vasquezu
Contributor
Contributor

This is still happening in version 2203. The best thing to do is what hermanc01 stated.

In my experience manual refresh will usually fix it. If it does not you can edit the database manually; HOWEVER, proceed with caution so you dont cause yourself a bigger headache.

SchwarzC
Enthusiast
Enthusiast

I had four packages stuck, what a simple solution 🙂

NLAVOIE
Contributor
Contributor

Wow thank you very much. I had 4 attachements stocks again but no traces. I rescan and now they are gone!

Reply
0 Kudos