I am trying to configure vSphere Replication appliance on my home lab but run into issues.
I have enter the vCenter server IP address for "LookupService Address", SSO password and click Save and restart service. The VRM service will start quickly and return to the stopped state. I also received error"Server returned request expired less than 0 seconds after request was issued but is shouldn't have expired for at least 600 seconds"
I have checked the following so far but could not work out the problem:
- vCenter > Runtime settings > vCenter Server managed address is the IP address of the vCenter
- ESXi host > NTP servers is the IP address of the vCenter
Just coming back from my very first VMworld experience and I'm kind of super excited about my near future with my uprising career with virtualization (talking about hype with all of the new features and wonders that virtual admins can do). But, I have like two months with the next question rounding my head over and over again, "What should I no next...?".
I got my VCP6-DCV Certification almost two years ago (yeah I know, it expires next December 4th), and I have the task to update/upgrade it before that date, and there's where my "problem" started, I don't know which pad should I take know! Some guys from VMware told me: "you should go for a VCAP in deployment" (since I'm more in the deployment and services business), or "go for the VCP-NV, everything is going to NSX and cloud services, you will totally need it" or with all the news and synergy with AWS, "maybe a CMA could do the work..."
So, I don't know what to do! I hope some of you guys could share with me your own experiences and maybe, I could light my virtualization path a little more with your kind help.
I've just found that it's no longer working on ESXi 6.0U2 (5572656). I have the latest SMIS provider VIB installed from Avago, but no luck. All I can see is that my MSM is sending SYN packets to the ESXi host on 3071
I have a lot of .ova stored VMs that are not 100% meeting the .ovf spec. It would be nice if you could override the hardware compatibility check when importing from .ova/.ovf with the fusion GUI. Maybe sneak this feature request into a dot release later this year? Thanks, Blake
Is there a way to configure a virtual HDD connected to the guest via a USB controller?
I have a need to create a virtual device that looks to the guest as a USB connected Mass Storage Device.
It seems like the guest configuration dialogs only allow adding actual USB devices unto a USB controller, but not hard drives. HDDs seem to be connectable via a plethora of controllers (IDE, SATA, SAS etc.) but not USB.
I've run into an error that I believe is new with vRO 7.3 as we've just upgraded vRA to 7.3 and its our first time seeing this. We have a workflow we call after a system is built that runs customization scripts. Generally we only ever need to run a single script but for a few situations we run a script, reboot, then run a second script. When we attempt to run the second time around I am getting an error "Unable to initialize a workflow handler" on the second script run. I can immediately re-run the failed workflow and it works. It seems like it only fails when called the second time inside of the parent workflow. Anyone seen this? Seems like a bug in 7.3. Maybe due to nesting or some other issue?
First time posting here but looking for some assistance/guidance
Background: Utilizing PCoIP/Teradici, VM's for this selected use are in a 'Floating' desktop assignment as they are generic VM's for use
We are running into an issue with deploying some handheld scanners that interface with an application on our VM's. The scanners use a USB to COM port driver which we have installed without issue, we can get the scanners connected and working just fine. Once we have them situated on that front we then have to load the application that they interface with and essentially 'setup' the scanner for use with the program, meaning we have to tell the program what COM port to listen to. The problem is when a user logs off of the VM and another use logs on the COM port can, and in most cases, changes on us thus meaning the scanner has to be setup again to be used on the application. Is there any way either in the VMware side of things, or in some other aspect, to essentially 'set' the COM port for the scanner to be consistent throughout the environment?
Between speaking with customers, architecting and deploying solutions, and helping others out with their issues on the VMware Communities forums, I encounter a lot of problems and get a lot of info on how customers do business with their CMPs. One of the requests that keeps coming up over and over again is how to deal with putting vRA’s workloads into the correct folder structure that has already been established in an enterprise. Very often—especially in large vCenter servers—companies have an established folder structure which could be quite complex. It is not unheard of to see a tree structure ten levels deep. These folders not only serve the purpose of providing visual VM organization, but also in defining permissions, monitoring, and backup boundaries. Permissions can be assigned at those folders granting access to the responsible parties. Folders, for example with vROps, can segregate monitoring policies. And just about every backup application on the market can now use vCenter folders as their organizational concept when setting up jobs. So they tend to be very important to certain organizations in a variety of ways. When implementing a CMP it is therefore important that it be able to fit into the established folder schema.
vRealize Automation (vRA) is certainly capable of putting its VMs into folders. In fact, if you changed nothing out of the box, it deposits its deployed VMs into a default vCenter folder called “VRM”.
For smaller shops that don’t really worry about folders, maybe this is fine. Through use of custom properties, vRA can stash those VMs into a folder of your choosing. By specifying the property VMware.VirtualCenter.Folder, the value of which determines the folder, any system deployed from vRA will land in that folder.
Anywhere this custom property is present within vRA that a deployment “touches” will be inherited and applied. For example, if this property were applied at the vCenter endpoint level, a VM that is deployed to that endpoint will be affected by the custom property. Likewise, if this property is present on a business group, and a user from that business group requests a machine, that machine will go into the folder specified by the custom property. What happens if this property is present twice at different locations? In that case, an order of precedence applies where the property which occurs later overrides one earlier. For example, if the property were on both a business group and specified at time of request, the value at time of request would win. While this provides some level of customization above what the VRM default folder affords, it’s still not enough for many customers. The ultimate desire is to have vRA deposit systems into the exact folder given a number of variables that might include things like department, environment, geographic location, and application. That level of flexibility is just not possible in vRA today without taking to vRealize Orchestrator (vRO) and writing custom JavaScript code. Until recently, that last sentence was true, but now SovLabs has an answer that changes everything and gives you the power you need.
With the 2017.3 release of SovLabs Extensibility Modules for vRA comes a new module called the SovLabs Property Toolkit for vRealize Automation. This module has two main abilities. The first is to change and manage custom properties on systems after they have been deployed. This is extremely powerful, as this kind of functionality does not exist natively in vRA and requires custom vRO workflows and code today. The second capability, the subject of this blog and the answer to our prayers, is to create dynamic property sets or groups of properties. With dynamic property sets, each property within the set can derive its name and value based on the value of other vRA custom properties or any custom logic utilizing the SovLabs Template Engine. With a dynamic property set, you can now derive a value for VMware.VirtualCenter.Folder from VM properties, including user-input values at request time. Let’s dig in and see this in action.
Imagine the following scenario, which I’ve taken from a real customer setup but made my own alterations: Your organization is very strict in its vCenter configurations. With over 4,000 virtual machines, you have to be organized. Further, with multiple locations, multiple lines of business, multiple environments, and even more applications, things get downright dirty if they aren’t carefully organized. This is the folder organization we must achieve.
Backup jobs are organized by these folders with specific retention policies applied due to regulatory compliance requirements. And your operations team allows access to these applications from the app teams themselves, which means you can’t give open access to everything in vCenter. This scenario is very real for many organizations. Let’s see how the SovLabs Property Toolkit module can easily handle this type of structure.
As shown above, we have a 5-level folder hierarchy in which we want vRA to stash machines that result from deployments. There are multiple options at each of these levels. For example, let’s start and assume we have the following specific structure: Southeast -> Inside -> Sales -> Production -> Oracle. We need to create labels for each of these levels and put them around vRA for the module to consume. The reason is simple: vRA services multiple regions, groups, departments, environments, and applications, and we must be able to distinguish between, say, Oracle and Sharepoint for each combination thereof. We’ll create custom properties for each of these levels in the hierarchy and apply them to the relevant constructs within vRA. This is a table of the custom properties I’ve created, their value, and where they reside.
Property Name
Value
Location in vRA
VCFolder.Region
Southeast
Cluster Compute Resource
VCFolder.BusGroupDept
Inside/Sales
Business Group
VCFolder.Environment
Production
Cluster Compute Resource
VCFolder.Application
Oracle
Blueprint (show in request)
The cluster (of which there is only one since this is a lab) has the Region and Environment properties, but imagine that we had multiple clusters, one for production and another for non-production. Those properties would then be split up. We’ve created a business group called “Inside – Sales”. There are others that begin with “Inside” but might be “Engineering” or something similar. The names are effectively two components of our folder naming plan. Lastly, the application is defined in our property dictionary and presents as a drop-down list of application names. This property has been added to our blueprint and is being shown to users in the request form. The reason being that, in this scenario, we’re only deploying IaaS and not PaaS, so applications have yet to be installed.
Now comes the magic. We have our property names established and configured. It’s time to configure the integration. For this, we must create a new custom property beginning with SovLabs_CreateProperties_. This prefix is required and is how the module knows to invoke the action defined in its value. In this case, I’ve created SovLabs_CreateProperties_VCFolder. I’ve done this directly on a test blueprint we’ll deploy in just a minute. The value is the most important part as it is JSON describing how the VMware.VirtualCenter.Folder property is to be constructed.
With this value, we are telling it to templatize the VMware.VirtualCenter.Folder property from all the constituent parts it comprises. The forward slashes denote the hierarchy.
Ah, so we see the individual folder create tasks hit vCenter. By default, vRA will look for the value of VMware.VirtualCenter.Folder, and if it doesn’t exist it will create every level that is present. This shows we’re on the right track with a result.
Alright, that’s what we want to see! Is that not cool?! Once the machine is built, we can check the properties tab (presuming you have business group manager role assigned) and see the resulting custom properties from all over that applied to the deployment.
So as to be expected, the module gathered our custom properties from all around vRA and, based on the template we defined as the value of SovLabs_CreateProperties_VCFolder, patched together the VMware.VirtualCenter.Folder property dynamically at build time all without having to write so much as a single line of JavaScript. That’s pretty amazing and powerful functionality right there, especially keeping in mind that if another user were deploying from a separate business group, the resulting folder would be different, so entirely dynamic.
I hope this small tutorial has piqued your interest in the possibilities this module unlocks. The sky is the limit. Next time, we’ll look at another common use case for this SovLabs Property Toolkit module: Multiple property background assignment.
Есть СХД, подключенная к Windows Server 2008 R2 по FC. На ней расположены базы MS SQL Server. Есть необходимость эти базы перенести на новую СХД, которая подключена к vCenter (VMFS6).
Можно как-то подключить старую СХД без форматирования и потери данных по FC к vCenter, чтобы быстро скопировать данные?
Hi, i want to change an edition of vCenter license from Essential 6.0 to Standard 6.0. Do i need to change only license in vCenter for this OR i need to reinstall the vCenter to apply new features?
We create shotcuts in the startmenu with VM UEM, with the following options: "skip if shortcut already exists" and "Undo at logoff".
I noticed that if a pc is shutdown without normal logoff (power out etc) the shortcuts that remaine, (which is normal, because flexengine hasn't run) are not removed in the next (normal) logoff .
I looks like only shortcuts created in one logon logoff cycle are removed. Is that normal behaviour?
when we update a shortcut, with for instance an new executable, it is never distibuted if the old shortcut still resited op de PC.
Is it a better option no to select "skip if shortcut already exists" so that the shortcut is Always recreated?
Or should I run a logon script that first clears out all of the shortcuts created by flexengine?
