VMware Horizon Community
AD879T
Contributor
Contributor

Attach package 4.x via vCenter

Hello

For testing purposes we used to attach AppStacks *.vmdk files directly to virtual machine via vCenter using VM Edit Settings -  Add NEW DEVICE - Existing Hard Disk.

Once AppStack *.vmdk is attached, user can run application stored in AppStack.

== However ==

When I try to attach Package *.vmdk file to VM directly via vCenter, VM OS does not see content of the Package.

Question: Is this package 4.x behavior done by design or we have a problem in our system?

Alex

13 Replies
Ray_handels
Virtuoso
Virtuoso

You did make sure that you attached a drive letter to the disk? Normally these are created with a disk setting that it does not automatically receive a drive letter.

Also make sure to show hidden and system files.

Reply
0 Kudos
AD879T
Contributor
Contributor

Hello

Thank you very much for the answer.

Just imagine. I have simple AppStack2.x and also Package4.x containing Firefox code and on desktop (C:\Users\Public\Desktop)shortcut to the firefox.exe.

If I attach that AppStack to user's machine (running AppVol 2.x Agent) directly via vCenter as an existing disk, user will get on his desktop shortcut to the firefox.exe and he can run it. AND user will also see "C:\Program Files\Mozilla Firefox\". There is no need to assign any drive letter to the attached AppStack disk for Firefox to work.

==however==

If I attach that Package to user's machine (running AppVol 4.x Agent) directly via vCenter as an existing disk, user will not get on his desktop shortcut to the firefox.exe AND user will not see "C:\Program Files\Mozilla Firefox\".

Does AppVolAgent4.x work as designed or do we have an issue in our environment?

 

Alex

Reply
0 Kudos
Micheal_A
VMware Employee
VMware Employee

Is the Fire Fox a 2.x package when manually mount using 4.x agent?

If so, I would try manually mount a 4.x package with the 4.x agent.

I'm assuming that will work as expected, but the 2.x won't because it is a package that needs to be updated to 4.x.

I would have to talk to the engineers to confirm, but 4.x agent is only coded to mount 2.x packages and all other functions would only be available if you update to 4.x package. I will have to test this theory and see what I get in my lab.

VMware EUC by Broadcom
https://techzone.vmware.com/
Reply
0 Kudos
Raymond_Handels
Contributor
Contributor

Aah, now I get what you are trying to acheve, I thought you were adding it to a machine that does not have the Appvolumes agent just ot make sure that you are able tom look through the Appstack itself.

I don;t bleieve this is possible as @Micheal_A stated because Appvolumes 4 uses a completely different template. So my guess is that you need to convert it to a 4.x package and then you would be able to attach it to a 4.x agent.

Reply
0 Kudos
AD879T
Contributor
Contributor

Hi

Note: Of cause, if you are attaching an Appstack2.x *.vmdk or a Package4.x *.vmdk files directly via vCenter to a virtual machine, AppVolumes Mananger does not see that AppStack/Package as attached - but for testing purposes that is not needed.

I see there is still a confusion here, so once again:

I created Firefox AppStack2.x from 2.x template, so I get firefox-2x.vmdk. I attach that 2x vmdk directly via vCenter to a virtual machine running AppVolume2.x Agent => user on that virtual machine can use Firefox w/o any issue. From user perspective, it looks like he has Firefox AppStack2.x attached.

I created Firefox Package4.x from 4.x template, so I get different firefox-4x.vmdk. I attach that 4x vmdk directly via vCenter to a diferent virtual machine running AppVolume4.x Agent => user on that virtual machine does not have Firefox available. From user perspective, it looks like he does not have Firefox Package4.x attached.

Alex

 

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso

I do understand that the manager won't see that but the thing is that the template (the VMDK all appstacks are based on) or so much different that I don't think you will be able to use a 2.x VMDK on a 4.x agent so what you are seeing is by design, at least that would be my understanding.

What happens if you browse to the Firefox installation folder after attaching the 2.x appstack to a 4.x machine?

Reply
0 Kudos
AD879T
Contributor
Contributor

Hi

I please, read my post carefully. I am attaching AppStack 2.x (based on 2.x template) on the machine running AppVolAgent2x and all works fine.

Then

I attach Package4.x (based on 4.x template) on the machine running AppVolAgent4.x and user does not get application in package.

 

Please, understand that I AM NOT mixing 2.x w/ 4.x at all !!!

 

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso

Oh man, sorry now I understand.. Man did not read that correctly.

When migrating from version 2.x to 4.x the option to deliver the application "On Demand" (directly even if the user is logged in) has been removed because they were either unable or not willing to add this feature because it did have some issues with the 2.x version, mostly the option to remove the application when the user is logged in.

 

It seems that the 2.x agent is capable or "importing" a manually added disk immediately whereas the 4.x agent is unable to do so.

That being said, the new Appvolumes 4.x agent (2111) has a new feature which is called App on Demand. My guess is that this is what you need or want to have. Do keep in mind (haven't had a chance to test it) that you need to create a new package and mark in On Demand

Apps On Demand
Now applications can be delivered on-demand when a user clicks to launch the application from the desktop and start menu just as if the application was already installed natively on the Windows machine.  The setting is available for newly created packages and the admin has an option to select on-demand for this new type of delivery, or classic, to have the user and computer assigned applications delivered at login and startup as they have in the past.

Reply
0 Kudos
Micheal_A
VMware Employee
VMware Employee

Now that I fully understand your question and scenario.

A lot of 2.x features where disabled in 4.x and may or may-not come back. This is most likely the reason you can't manually mount the AppStack/Package using the 4.x agent.

With that said, VMware does not support that kind of testing. We only support mounting the VMDK to a non-agent VM to make configuration changes within the VMDK.

Packages (VMDK) must be tested through AppVolMgr mounting to validate the package is 100% functional and working without ERRORS.

I'm 99.9% sure the VMware product team will never add the functionality as a GA release. But you can always put a feature request in and if you get enough votes the product team will look into it.

Here is the KB and link to submit a request.

https://kb.vmware.com/s/article/1002123

https://wsone.ideas.aha.io

 

 

VMware EUC by Broadcom
https://techzone.vmware.com/
Reply
0 Kudos
AD879T
Contributor
Contributor

Guys, thanks for answer

In this discussion, we came to the conclusion that the 2.x agent is capable or "importing" a manually added disk immediately whereas the 4.x agent is unable to do so.

We have AppStcks2x and Packages4x stored on multiple datastores (storage group). When mounting AppStacks/Packages automatically via AppVolManager you never know from which datastore the appstack/package is mounted on VM.

Mounting AppStacks2x manually directly via vCenter allows you to select an individual datastore to mount AppStack/Package from. In case of problems, thus we tested individual AppStacks/datastores.

Well, it looks like we cannot use such a method w/ Package4.x.

Reply
0 Kudos
Micheal_A
VMware Employee
VMware Employee

When you are packaging the files never get replicated, they will be stored on the default local datastore till you publish the package. So you should mount only from that datastore.

You should never have to manually mount the package while your in the packaging status in AppVolMgr.

VMware EUC by Broadcom
https://techzone.vmware.com/
Reply
0 Kudos
AD879T
Contributor
Contributor

We used the method to mount AppStacks from a particular datastore for troubleshooting purposes not for packaging process.

Example:

We have working AppStacks on many Horizon floating pools - all looks good everyone is happy. Storage team made some upgrades of their LUNs => users start reporting various issues that their AppStacks sometimes were not mounted.

So we tried mounting AppStacks manually one-by-one from different datastores. Thus you can find that for example AppStack8 is having an issue when mounted from datastoreD (while AppStack8 works perfectly fine when mounted from datastores A,B,C,E and F).

Reply
0 Kudos
Micheal_A
VMware Employee
VMware Employee

That is a infrastructure issue and the way your datastores get updated. You should not have to do any of this manual troubleshooting. You can use log monitor and/or look at the AppVolMgr and vCenter logs to find out what the actual cause of any AppVols package mounting issue.

In all the clients I have deployed AppVolMgr, which is a lot, I never had anyone try to troubleshoot the way you do.

I suggest you create a log bundle from AppVolMgr UI and look for the ERRORS for the that user you got a ticket on.

Also, If your VCF team is making updates without your knowledge, that is the root issue to your problem, not App Volumes.

We have always known that App Volumes will reveal infrastructure issues that is not an AppVolMgr, it just raises the issue.

FYI, If a package mounts on one VM with no problems, then you know in is an underlining issue that should be tracked by logs. (Look in your AVM UI under the activity tab.

We have KB's on logging and I'm sure you can find more AVM troubleshooting steps here in this site.

 

 

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