Regarding the original multiple paths idea, being able to define multiple VM profiles for a single VM host is desirable. Rather than add additional complexity to the VM profile table, I would prefer to be able to define multiple vmhost entries for the same physical VM host computer. One benefit of this approach is that it doesn't require any changes to the vcld code.
I have configured this manually in some situations in our environment by manually adding entries to the vmhost table with the same vmhost.computerid value but different vmhost.vmprofileid values. This was done to be able to define a different datastore for some special purpose VMs. With the new vmprofile.resourcepath and folder path options, being able to define multiple profiles for the same host would be more valuable. Additional comments below... On Thu, Jan 17, 2013 at 3:11 PM, Aaron Coburn <[email protected]> wrote: > > We have made some changes to the backend SAN Datastore that significantly > reduces the I/O congestion, so I don't presently have a need to add > multiple datastores to a given vmhost configuration. If that becomes > necessary, I will write some code to implement that. > > On our system, in addition to moving the workspace datastore to faster > disks, I made another change, with which we are currently experimenting. I > would be curious to know what you think. I would be happy to submit the > relevant changes if there is interest. > > In looking into the source of this I/O spike, it appeared to be > originating from the concurrent creation of the users' default profile in > Windows 7. Specifically, at the beginning of a block allocation in which a > large number of reservations begin simultaneously -- and therefore each > environment copies the default profile at about the same time, this puts a > huge I/O load on the backend datastore. The CPU and Memory usage of the > server cluster remained very low at the time, but the I/O congestion > rendered the VCL almost unusable. > I have seen similar problems before, especially when Adobe/Macromedia apps are installed. They can add 100's of MBs to the AppData directory in the user profile. If the apps are run when setting up the default user profile, this data is copied to the new user account's profile before the desktop appears. If not, the data is copied when the user first launches the app. > > What I have done is add an additional field to the image table, where the > name of a default user account can be stored. Then, when such an image is > created, that user account can be pre-created similar to the steps > currently outlined for configuring the default profile [1]. When the image > is captured, the account is disabled but not deleted. > > When a user makes a reservation for the image, this default user account > is enabled and a password is set. Then, the user is provided with login > credentials for this account. When the user connects to the image, the > profile is already setup, and hence the login time is significantly > reduced. If the account does not exist on the image, it is simply created > anew. > > I realize that this would not work for systems that integrate the Windows > OS-based login with a campus AD backend, and it may be potentially > confusing for users who are asked to login to a VCL environment using some > arbitrary username (i.e. vcl). Neither of these are issues in our setup, > because images are not tied to campus services and users can auto-connect > to their reservations (without typing the vcl-generated password), but > others may find this unappealing. This also isn't relevant for linux-based > images. I really like the idea of pre-staging the user account. This would speed things up for end users. It would also make it much easier for people to configure the default profile. There are problems with the steps explained in [1]. The profile directory path of the configuration account often gets saved in several places in the registry such as C:\Users\Profile. This causes various problems. How about pre-staging the user account as you have described and renaming it when an image is reserved via: wmic useraccount where name='oldname' rename newname If the user account is renamed, do you still see the need to use different account names for different images or could the same name be used globally? Also out of curiosity, how are you doing the auto-connect? Could it be added as an optional feature? Thanks, Andy > Aaron > > [1] http://vcl.apache.org/docs/configure-the-default-profile.html > > > > > > On Jan 11, 2013, at 4:35 PM, Josh Thompson <[email protected]> wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > If this works best for the backend, I'm good with making it happen on the > > frontend. > > > > Josh > > > > On Thursday, January 10, 2013 9:35:50 PM Aaron Coburn wrote: > >> Hi, > >> > >> The VCL currently allows VM Host profiles to identify a single "VM > Working > >> Directory Path", which can be either a dedicated or shared disk. All > >> running VMs on a given host will use this datastore path for I/O > >> operations. > >> > >> In our system, we are using a clustered VM host (VMware vCenter) > >> infrastructure connected to a shared network (SAN) storage array. In > the VM > >> host profile, the "Virtual Disk Path" and "VM Working Directory Path" > use > >> separate datastores, each of which use distinct storage processors in > the > >> SAN. But still, all running VMs in the cluster use the same datastore > for > >> their working directories. > >> > >> We have recently been encountering some significant I/O congestion on > the > >> host bus adaptors that connect to the VM working directory, resulting in > >> really high I/O latency. > >> > >> My current thinking on this is that I would like to make it possible > for a > >> VM host profile to identify multiple paths for the "Working Directory". > >> This would mean that the path for a given VM would be determined via > round > >> robin. This would obviously have certain implications for the database > and > >> existing provisioning module code, as well as involve some front-end GUI > >> work. > >> > >> Do any of you have thoughts on this? > >> > >> Thanks, > >> > >> Aaron Coburn > >> Systems Administrator and Programmer > >> Academic Technology Services, Amherst College > >> [email protected] > > - -- > > - ------------------------------- > > Josh Thompson > > VCL Developer > > North Carolina State University > > > > my GPG/PGP key can be found at pgp.mit.edu > > > > All electronic mail messages in connection with State business which > > are sent to or received by this account are subject to the NC Public > > Records Law and may be disclosed to third parties. > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v2.0.19 (GNU/Linux) > > > > iEYEARECAAYFAlDwhb8ACgkQV/LQcNdtPQOS2ACeMSw188W0zNWv9dSuHdoY/JE7 > > OhEAni0ga32Oawpwwcs4wljl21BadzzI > > =cyuN > > -----END PGP SIGNATURE----- > > > >
