VMware Horizon Community
HPU-ADM
Enthusiast
Enthusiast

App Volume 2 vs 4

Can someone post in a nutshell why i should be going to version 4?

My environment is hitting a hard wall where I can't upgrade view past 6.  Technically I could upgrade my connection servers to 7.10 or 7.11, but i would have to continure to use view agent 6 because that's the highest version view agent, a zero client tera1 chip will connect to.  I don't have App volumes but will start building that shortly and will have to go with 2.18 and not 4 because App Volume 4 is compatible with 7.10 and 7.11.

17 Replies
martinturner
Contributor
Contributor

Right now there isn't a massive difference. v4 looks to be migrating away from the idea of managing collections of apps and instead individual apps with versioning (allowing you to have different people have different versions of the app if there are compelling reasons to do this, say plugin compatibility). 2.18 is LTS though so it'll be supported for a bit longer yet (2.18.1 is out already).

You should probably be looking at plans to move away from view 6 though (even if its new hardware migration) because eventually none of it is going to be supported and its better to be ahead of the game.

Ray_handels
Virtuoso
Virtuoso

The biggest advantage I can see now in version 4.0 is that you can create a package for every application. It depends on your use case of course but if you have applications that are now installed in multiple appstacks because you don;t want to have to many appstacks this is much better.

Looking at administrative effort, Appvolumes 4.0 is much nicer and easier to use than the old 2.x version. But I gues it is a matter of taste.

And View 6 is a definite no go as far as I'm concerned. Try and upgrade to 7 as fast as possible.

raybarth
Contributor
Contributor

In support of what the previous replies have stated about individualizing the packages, 4.x looks be more aligned with the JMP server and it's ability to provision to a more individual's needs.

Reply
0 Kudos
Natestack
Enthusiast
Enthusiast

think I will stick with 2.x why cause to repackage every application is crazy understand paid applications and standalone but let’s say your like me and have every user gets a corporate stack with everything a base user needs.

example

7zip

Firefox

Chrome

Flash

Outlook add-ins

Adobe Reader

Putty

NotepadC++

plus many more let’s say 30 individual apps in one stack

all this work takes me about 15mins install reboot done

with 4.0 do the 30 in individual apps would take hours

plus let’s not forget about log on times.

tried to do multiple applications in 4.0 says it will run on windows 10x86 WTF I did all this on x64 how on earth do I get this added to also run on windows 10x64 bit and or Win7 I know it’s dead but still.

anyway personally I know with 2.x I can at least tell it run on win x86/64 server 2008/12,16 etc

Personally I think if you can change it on 4.0 to tell it run on Windows versions xyz that would be nice to know how.

thanks,

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso

Here's a link on how to add it to different OS'ses but as said on another post I would not do that.

https://vdr.one/app-volumes-4-0-app-stack-os-mount-hacking/

That being said. You can still have multiple applications within 1 package and call the application Base.

The reason why I would not suggest doing this in Appvolumes 4.0 (and the reason why i really like the way it is setup now with 4.0) is that if you do have multiple applications (let's say 20) and you only need to change one you would need to change the entire appstack which could cause other applications not to work. Apart from that maybe someone wants to have a different version of one of those specific applications. you would need to create multiple appstacks to provide everyone with their specific version. Let alone testing the entire appstack every time even though you only update 1 application.

Still. At the end it depends on what you are trying to achieve with Appvolumes and DEM i guess and whichever suites your needs best. I do think that in the end the 2 version will disappear.

raybarth
Contributor
Contributor

For what it is worth.  You can still setup 2.x appstacks within version 4.  Take a look at the techzone info.

What's New in VMware App Volumes 4 | VMware

Reply
0 Kudos
Natestack
Enthusiast
Enthusiast

Not if your using 4.0 client you can’t

If you install 2.x client you can have the 2.x

Um on a side note

Noticed you cant on 4.0 delete multiple applications which is annoying testing creating random applications.

With 2.0 select the app stacks hit delete nice and simple 2 step process not individual that sucks personally for me.

Also doing a package and finding it sets it to Windows 10x86 is really annoying and i am tempted to do the database fix as above.

VMWARE gives us the ability to change what operating systems applications can be assigned to please.

Reply
0 Kudos
VirtualSpence
VMware Employee
VMware Employee

Also doing a package and finding it sets it to Windows 10x86 is really annoying and i am tempted to do the database fix as above.

Is this a label you're seeing that indicates Win10x86? Or are you unable to attach the Package to an x64 system? If it's the former, this could be a simple bug in the gui that wouldn't impact usability. If it's the latter, it obviously affects usability of the product.

Josh Spencer Staff Architect – Technical Marketing End User Computing, VMware, Inc.
Reply
0 Kudos
martinturner
Contributor
Contributor

So for migrations VMWare have a fling for this: App Volumes Migration Utility | VMware Flings

It'll (hopefully) take an existing app stack and just convert it to the new 4.0 format, meaning you can migrate now and then slowly re-provision your apps in to single appvolumes over time. I mean you are updating the apps anyway right?

I'm holding off until I see 4.1 (or 4.0.1 at least) as its supposed to bring back the 'limit attachments' checkbox which we actually use here (I have a small 3 machine dev pool to test various updates/changes)

Reply
0 Kudos
jmatz135
Hot Shot
Hot Shot

I don't really get this "feature".  You could always put one app in an appstack and if I really wanted call it a package.  This isn't exactly anything new.  The only problem is if you had 20 appstacks (packages) it would take forever to login, which of course in app volumes 4.0 it takes forever to login with 20 packages applied anyway, so...

The other issue is there is a limit to the disks you can have per storage controller on the VMs themselves:

The maximum number of disks depends by the controller type:

  • Max 4 virtual disks on IDE controllers
  • Max 60 virtual disks on SCSI/SAS controllers (up to 4 controllers)
  • Max 256 virtual disks on PVSCI controllers (up to 4 controllers) new in vSphere 6.7
  • Max 60 virtual disks on NVMe controllers (up to 4 controllers)
  • Max 120 virtual disks and/or CDROM devices on SATA controllers (up to 4 controllers)

SCSI is the default and most don't change it so you can go to 60 virtual disks.  That is 59 packages that you can have max from what I can tell unless I'm reading this wrong and you would have to have 4 storage controllers to do it.

Reply
0 Kudos
jmatz135
Hot Shot
Hot Shot

Sorry, it is 60 virtual disks per controller so in theory you could have 240 virtual disks.  Still I don't like having a ton of virtual disks attached to every VM in my environment.

Reply
0 Kudos
martinturner
Contributor
Contributor

Restriction aside (at least in my environment users tend to have a dozen or less apps, with the "common to everyone" apps in the base image) you can indeed already do this with the exist appvolumes. I in fact already do this with the existing appvolumes and we haven't upgraded to 4.0 yet. My understanding was it was more of a logical change in that you now get apps in the interface with versions listed under each app, rather than the existing version were you just get a big long list of appstacks split up however you happen to be naming them. I know I'll be using the versioning quite heavily when we eventually upgrade as I've already pretty much started to use my own versioning system in the current version (i include a date a build number in the appstack name).

I was hoping the 'under the hood' changes they were making would have speed up app stack attachments to the point where having 20-30 appstacks per user wouldn't be an issue. Right now its bearable to log in (at least on my setup) with 5-10 appstacks but realistically anything past that makes logging in take so long you start to get complains.

In my head I've been treating 4.0 more like 2.19 (with 2.18 being LTS anyway) with the caveat that once you've upgraded there is no going back.

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso

I see quite some posts of people saying that login with 4.0.1 is slower than 2.18 (or older versions) but I don't see that at all.

Looking at my use case (and I guess many more), even i you have 1 base appstack with 15 applications (we also have one of those) we still decided to create 1 package per application. If you only need to update 1 application you can simply update that 1 version and assign it to 1 person to test it as a single assingment takes precedence over a marker or group assignment. If you don't see the benefit of that my guess is yoyu didn;t really push to the limit of appvolumes yet.

We also had an issue with adding more than 14 appstacks but looking at logs this seemed to be quite obvious as we  needed a new scsi adapter for the extra disk and you can't hot add that. But with a testing machine with W10 not optimised and no virusscanner and stuff (as said, very simple test) we added 16 appstacks and login time was about 20 seconds. And this waas not only simple applications but also big ass Adobe stuff.

My guess is that we all try to cramp up a bit to much on the virtual machines like DEM, virusscanning and then some that slows down the logon of the machine. also modern apps are a really quick logon killer for W10..

SanderMors
Contributor
Contributor

Bit late.. we came to the conclusion that we can no longer choose to assign an 4.0 Application to a specific OS afterwards anymore. Of course, we know the risks of unreliable behavior.. but still for simple applications it was an outcome.

We now first have to decide whether to provision the software on Windows 10 or Windows 2016/2019. Or make use of a Desktop Application pool to provide the Application directly via our portal.

Below the rich option list from 2.14 we miss 😉

pastedImage_0.png

Reply
0 Kudos
Natestack
Enthusiast
Enthusiast

Totally agree i advise back on 02-Mar-2020 14:41

I did a package (NotepadC++) on windows 10x64 1809

Once package complete gone to assign to the rest of my test machine which are Windows 10x64 1809 and wont assign checked and the application will only attach to windows 10 x86

I've been waiting for VMware to release the new version that allows us the ability to change this.

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso

You guys did see this link right?

Here's a link on how to add it to different OS'ses but as said on another post I would not do that.

https://vdr.one/app-volumes-4-0-app-stack-os-mount-hacking/

I suspect that the newer version will support this and also the computer prefix but it seems as if 4 first needed to come out so people could see it.

They are now adding the stuff from the old 2.x version to it I believe.

Reply
0 Kudos
Natestack
Enthusiast
Enthusiast

Hi Ray,

Been waiting patiently for an update.

over 3 months and counting I suspect it will be a big change coming just hoping this is the case keen to use the latest and greatest as I would assume Office 2019 will be Supported and touch wood we don’t have issues with Visio/Project and have the ability to change OS.

Thanks,

Nathan

Reply
0 Kudos