1 2 3 4 Previous Next 51 Replies Latest reply on Apr 1, 2013 6:35 AM by gkho978 Go to original post
      • 30. Re: VMware Studio v2.2(?): Feature requests / User wish list
        provision Hot Shot
        VMware Employees

        With Studio 2.5, here are some status updates to the FR's:

         

        Resolved:

         

        #023, #010, #011, #017, #018, #008

         

        Improved:

         

        #002 - You may now create new disks that are LVM formatted.  LVM on root disk is not supported yet.

         

        #016 - The network configurtion utility used by the blue login screen on the VM console has been rewritten.

         

        #024 - Some logic for supporting Windows guest OS has been changed and made easier to accomodate custom Windows ISO.

         

        Give Studio 2.5 a try.

        • 31. Re: VMware Studio: Feature requests
          mshamma Novice

          Why is setting the hostname disabled when dhcp is enabled? If there is no fundemantal reason for this disable, how do you recommend that I hack my way through setting the appliance hostname?

          • 32. Re: VMware Studio v2.7(?): Feature requests / User wish list
            Jogarem Enthusiast

            FR #029:

             

            It would be great and would spent a lot of time if it would be possible to update one or more packages only instead of building a whole appliance.

            The reason for that is that atm you need to build the whole VM which is time consuming and bad because each build process could have a fault which the previous may not had before.

             

            It would be really important for us if there would be an option to:

             

            • check the defined repo-path(s) and compare them with the online-repo
            • update the online repo if needed (and only then of course)

             

            Some thoughts about the GUI part:

            Besides the "Edit Profile", "Build VM" , ... there could be a button "Update Repository" which then skip the build but doing the package updates only.

             

            Because of like it is atm we're thinking about switching back from Studio to an own udpate-process because we are more flexible then

            Even if that means we need to create a Web-GUI for the apt-get dist-upgrade process.. but maybe VMware could integrate such a requested option so we don't need that

             

            Thx

            Thomas

            • 33. Re: VMware Studio v2.7(?): Feature requests / User wish list
              dkhan Novice

              I have a few items that I woudl like to see:

               

              1.  During firstboot the hostname is not set correctly. I have noticed that the public hostname is added to the internal loopback entries, e.g.

               

              127.0.0.1 publichostname.com localhost localhost.localdomain

               

              That's not the correct way to update the hosts file. The public hostname and it's address should be in its own hosts entry,

               

              127.0.0.1 localhost localhost.localdomain

              192.168.1.100 publichostname.com publichostname

               

              This is the proper way to set hostnames in /etc/hosts. Some applications do not lik ethe public hostname to be mapped to the loopback address.

               

               

              2. The vApp deploment wizard needs to be restructured. I build vApps consisting of up to ten VMs. The resulting network input form is a single column with alternating fields for each network property (gateway, netmask, address, DNS). Both internal and field experience has shown that this is very error prone. I keep getting support problems with this layout. Some organization would be better, e.g. a grid of nodes to network property fields would be better than a single list.

               

               

              3. My vApp application consists of multiple VMs which are the same source VM. It would be nice if the vApp build was smart enough to package a single template (VMDK, etc) for each VM type so that the vApp deploymetn package (e.g.ova) is smaller. For example I have 2xnode_type1, 3xnode_type2, 4xnode_type3. The result is nine sets of VMDKs. Ideally it would be nice to have just three VMDKs in the OVA and at deployment time the correct number of VMs could be deployed.

               

              4. None reliance of DNS for reverse lookup to set the hostname.  I've had a lot of support calls because the customer does not have correct reverse lookup entries in their environment. Ideally the wizard could have a field to set the hostname when the nodes are not in DNS.

              • 34. Re: VMware Studio v2.7(?): Feature requests / User wish list
                dkhan Novice

                How about profiles for the newer releases of RedHat, e.g. 5.7, 6.3. Same for SLES. This could be released in the forums as the new OS's are GA'd. 

                • 35. Re: VMware Studio v2.7(?): Feature requests / User wish list
                  asharpe Hot Shot
                  VMware Employees

                  Actually, we were hoping to leverage the community for this. It is difficult to keep up with all the different versions of all the distros, so if folks could post their modifications for specific OSs, everyone would benefit.

                  • 36. Re: VMware Studio v2.7(?): Feature requests / User wish list
                    asharpe Hot Shot
                    VMware Employees

                    Some responses to your requests:

                     

                    1.   During firstboot the hostname is not set correctly. I have noticed that  the public hostname is added to the internal loopback entries.


                    Since the DHCP daemon in the OS itself does this, Studio does the same.

                     

                    2.  The vApp deploment wizard needs to be restructured.

                     

                    Unfortunately, there is nothing Studio can do about the presentation of properties in the VI Client. You should voice this concern in the vSphere communities, where they may be able to tell you about future improvements to the layout.

                     

                     

                    3.  My vApp application consists of multiple VMs which are the same source  VM. It would be nice if the vApp build was smart enough to package a  single template (VMDK, etc) for each VM type so that the vApp deploymetn  package (e.g.ova) is smaller.

                     

                    There is an option using ovftool that makes "delta disks", coalescing the common blocks of multiple VMs, but it is not a widely used feature.

                     

                    4.  None reliance of DNS for reverse lookup to set the hostname.  I've had a  lot of support calls because the customer does not have correct reverse  lookup entries in their environment. Ideally the wizard could have a  field to set the hostname when the nodes are not in DNS.

                     

                    If there is no reverse lookup of the hostname, then the hostname itself is rather useless. If nobody can use it, why have it? A server appliance should have a static IP and a name in the DNS servers as a best practice. Running a server in a development or debugging environment is one thing, but when the appliance goes production, it really needs to be in the DNS.

                    • 37. Re: VMware Studio v2.7(?): Feature requests / User wish list
                      dkhan Novice

                      asharpe,

                       

                      I'd like to respond to your replies to my last post.

                       

                      1. Since the DHCP daemon in the OS itself does this, Studio does the same.

                      Just because DHCP does this does not make it right. This problem also occurs with the statically assigned addresses so it is not a DHCP specific issue.

                       

                      3. There is an option using ovftool that makes "delta disks", coalescing the common blocks of multiple VMs, but it is not a widely used feature

                      Yes I'm aware of the delta disks feature. It would be really neat if there was integration with this from within the VMware Studio web console. Maybe a checkbox in the Output section of the vApp profile editor.

                      4. If there is no reverse lookup of the hostname, then the hostname itself is rather useless. If nobody can use it, why have it? A server appliance should have a static IP and a name in the DNS servers as a best practice. Running a server in a development or debugging environment is one thing, but when the appliance goes production, it really needs to be in the DNS.

                       

                      Yeah, great way to pass the buck . I'd like to see you actually explain that to our customers and field service personnel. They don't buy it one bit. We do explicitly state that the customer's environment must have reverse DNS lookups but most customers never bother to do this. It causes a lot of problems. Why not have an option to set the hostname as part of the vApp deployment. this can be just another property like the rest of the network settings...or is this a vSphere issue.

                       

                      The issue is not about public applications trying to access the servers. The issue is that some applications in a multi VM vApp need to access services on the other VMs. In some cases a publicly accessible hostname is not necessary as long as all VMs in the vApp have the same hostname to address mappings. One can easily do this using an  /etc/hosts file across all of the VMs. Yes some of our customers do use the vApp in an eval environment without first setting up reverse DNS as they can use local hosts entries.

                      • 38. Re: VMware Studio v2.7(?): Feature requests / User wish list
                        asharpe Hot Shot
                        VMware Employees

                        dkhan wrote:

                        1. Since the DHCP daemon in the OS itself does this, Studio does the same.

                        Just because DHCP does this does not make it right. This problem also occurs with the statically assigned addresses so it is not a DHCP specific issue.

                        Right. We do it for static IPs the same way as the DHCP daemon does it to be consistent.

                        4. If there is no reverse lookup of the hostname, then the hostname itself is rather useless. If nobody can use it, why have it? A server appliance should have a static IP and a name in the DNS servers as a best practice. Running a server in a development or debugging environment is one thing, but when the appliance goes production, it really needs to be in the DNS.

                         

                        Yeah, great way to pass the buck . I'd like to see you actually explain that to our customers and field service personnel. They don't buy it one bit. We do explicitly state that the customer's environment must have reverse DNS lookups but most customers never bother to do this. It causes a lot of problems. Why not have an option to set the hostname as part of the vApp deployment. this can be just another property like the rest of the network settings...or is this a vSphere issue.

                         

                        The issue is not about public applications trying to access the servers. The issue is that some applications in a multi VM vApp need to access services on the other VMs. In some cases a publicly accessible hostname is not necessary as long as all VMs in the vApp have the same hostname to address mappings. One can easily do this using an  /etc/hosts file across all of the VMs. Yes some of our customers do use the vApp in an eval environment without first setting up reverse DNS as they can use local hosts entries.

                        Not passing the buck one bit. I explain this, as I'm explaining it to you, to customers all the time. It doesn't matter if they buy it or not; the fact is, a production server needs to be set up in a way that other machines and services can access it. And if you want to use a name to access it, you need to have DNS set up.

                         

                        The argument about a multi-VM vApp doesn't hold up, as the mapping in the OVF environment passed by vCenter only has the IP address and the *VM ovf:id* which has absolutely nothing to do with a hostname, and the OVF environment is how one VM discovers a peer in a multi-VM vApp.

                        • 39. Re: VMware Studio v2.7(?): Feature requests / User wish list
                          asharpe Hot Shot
                          VMware Employees

                          Note that, while I disagree with the need, Studio has a way to do what you want, regardless. There is a property called vami.hostname that will ask for a hostname when the VM is deployed to vCenter, and there is another variable in the build profile called vadk:SetHostname that you can set to false so that we won't reverse look up the IP address and override the hostname that you specify. Studio tries to accomodate, no matter what the requirement. Even if you don't use the vami.hostname property, you can add your own property, and retrieve its value with the ovfenv command in your firstboot script and set the hostname to whatever you want. As long as the SetHostname element in the build profile is false, we won't touch it.

                          • 40. Re: VMware Studio v2.7(?): Feature requests / User wish list
                            gxc422 Enthusiast

                            VMware Studio provides a great way for an appliance to be able to update the software on it.  There have been some items that I would like to see added in the next release:

                             

                            • Update VAMI to handle special characters.

                              One of the issues I face is that some environments have email address for username filed so that they can access the local repository.  It could also be another domain so someone would need to enter domain\\username.  I can do this under the provider.xml manually but could this javascript be updated to accept and transform to write the values for username and password?

                             

                            • Update Password Encryption.

                              It would be nice if the password was stored encrypted.
                            • 41. Re: VMware Studio v2.7(?): Feature requests / User wish list
                              Jogarem Enthusiast

                              Hi gxc422 and thx for your feedback!

                               

                              Your FR's are added to the list.

                               

                              Regards

                              Jogarem

                              • 42. Re: VMware Studio v2.7(?): Feature requests / User wish list
                                asharpe Hot Shot
                                VMware Employees

                                gxc422 wrote:

                                • Update Password Encryption.

                                  It would be nice if the password was stored encrypted.

                                Unfortunately, this is non-trivial for the provisioning engine passwords, as we have to use the clear text password to log into ESX/vCloud/vCenter. And if you encrypt it with a key somewhere on the filesystem, then you still have no security, because the key itself will also be in cleartext. Or, you invent a gpg keystore or somesuch, and hold the key to unlock the passwords, but then the security of the keystore has to be managed, and the passphrase for the keystore needs to be in cleartext. We thought about this a lot, which is why we give the option for DES for user passwords, have the option to generate a random password (that nobody knows, and the firstboot script asks for one), and use by default base64 (which is no security, but is helpful against shoulder-surfing).

                                 

                                Do you have suggestions?

                                • 43. Re: VMware Studio v2.7(?): Feature requests / User wish list
                                  mshamma Novice

                                  It would be great if VMware Studio 2.7 would support provisioning linux VMs from an Ubuntu 12.04 LTS ISO.

                                   

                                  Cheers,

                                  • 44. Re: VMware Studio v2.2(?): Feature requests / User wish list
                                    AITS Enthusiast

                                    Hi All,

                                     

                                    What all the sysadmin needs, a central tool which can drag the existing VM template and start push the application package and convert them to customizsed template.

                                    Is it possible in 2.7 version future release request.

                                     

                                    Regards

                                    - AITS