Ourcommunities are designed by division, as you can see below. Visit each division's homepage for a list of product communities under each division. From there, click on the communities you're interested in, choose "Join Community," and select your notification settings. It's that simple. Join as many as you'd like.
Register Here
Please note: Your first post to any of our communities will be placed in a moderation queue for review to help us prevent spammers from posting unwanted content. Our community managers closely monitor this moderation queue, and once your first post is approved, your posts will no longer go through moderation. Please do not submit the same post multiple times.
Check Out Our Events
Every business is in pursuit of growth. At Broadcom, we are helping customers embrace open tools and technologies, integrate their Mainframe as part of their cloud, and create new innovation opportunities that drive their businesses forward.
In the recent past, VMware introduced the all-new Developer Documentation. It had an intuitive UI, improved categorization, and a user-friendly Interface, which helped improve the information experience. Initially, it was only the API reference, and the PowerCLI documentation was not part of it. Later in the year, PowerCLI documentation was included, and we asked our community members to share the feedback. I thank our community members for stepping up and providing valuable feedback to us.
Now, We have the global search bar available at the PowerCLI homepage and on the product reference page. No matter what content you are viewing currently, The search bar is available across the PowerCLI documentation. You can now search the cmdlets, irrespective of a PowerCLI Module or a VMware Product.
PowerCLI is all about objects. The one thing which I found interesting is the data structure tab. With this, You can clearly understand an object and its properties. The data structure tab also provides the details of how this object is consumed via different PowerCLI cmdlets. Quite handy, must try out.
The cmdlet reference page provides a clean interface to get the details about a respective cmdlet. A well-informed description and neatly highlighted syntax help you to understand the cmdlets much better.
The cmdlet reference page also provides sample examples, which you can copy and modify according to your requirements. No matter if you are an experienced PowerCLI geek or a rookie, this cmdlets reference page will always be a great help to you.
The concept of salting has been introduced to help address concerns system administrators may have over the security implications of TPS as described in KB Security considerations and disallowing inter-Virtual Machine Transparent Page Sharing (2080735). Salting is used to allow more granular management of the virtual machines participating in TPS than was previously possible. As per the original TPS implementation, multiple virtual machines could share pages when the contents of the pages were same. With the new salting settings, the virtual machines can share pages only if the salt value and contents of the pages are identical. A new host config option Mem.ShareForceSalting is introduced to enable or disable salting.
By default, salting is enabled after the ESXi update releases mentioned above are deployed, (Mem.ShareForceSalting=2) and each virtual machine has a different salt. This means page sharing does not occur across the virtual machines (inter-VM TPS) and only happens inside a virtual machine (intra VM).
When salting is enabled (Mem.ShareForceSalting=1 or 2) in order to share a page between two virtual machines both salt and the content of the page must be same. A salt value is a configurable vmx option for each virtual machine. You can manually specify the salt values in the virtual machine's vmx file with the new vmx option sched.mem.pshare.salt. If this option is not present in the virtual machine's vmx file, then the value of vc.uuid vmx option is taken as the default value. Since the vc.uuid is unique to each virtual machine, by default TPS happens only among the pages belonging to a particular virtual machine (Intra-VM).
If a group of virtual machines are considered trustworthy, it is possible to share pages among them by setting a common salt value for all those virtual machines (inter-VM).
By default, after deploying the ESXi Update releases mentioned above salting is enabled (Mem.ShareForceSalting=2) and each virtual machine has a different salt (that is sched.mem.pshare.salt is not present) which means that only Intra-VM page sharing is enabled. This behavior is new as per these ESXi update releases and page sharing will not happen across the virtual machines (inter-VM TPS) by default.
How do I re-enable inter-VM TPS for selected virtual machines after deploying an ESX Update release that no longer has inter-VM TPS enabled by default?
Set MEM_SHARE_FORCE_SALTING to 1 or 2 and for the virtual machines you wish to share, set sched.mem.pshare.salt to a common value.
How can I allow inter-VM TPS between two or more virtual machines?
Inter-VM TPS is enabled for two or more virtual machines by enabling salting and by giving them the same salt value.
MEM_SHARE_FORCE_SALTING 1: By default salt value is taken from sched.mem.pshare.salt. If not specified, falls back to old TPS (inter-VM) behavior by considering salt values for the virtual machine as 0.
MEM_SHARE_FORCE_SALTING 2: By default salt value is taken from vc.uuidz. If it does not exist, then the page sharing algorithm generates random and unique value for salting per virtual machine, which is not configurable by users.
How to manage the additional Transparent Page Sharing (TPS) management capabilities introduced in the earlier TPS ESXi patches?
The following patch releases have introduced additional Transparent Page Sharing (TPS) management capabilities for the first time. KB Additional Transparent Page Sharing management capabilities in ESXi 5.5, 5.1, and 5.0 patches in Q4, 2014 (2091682) explains how to manage these capabilities when the patches are deployed and when the Update releases listed on the top of this KB are not deployed:
How can I prepare for the ESXi Update releases that no longer allow inter-VM TPS by default?
VMware recommends you to monitor free memory available on the host along with the total ballooned and total swapped memory before deploying the ESXi update releases listed above that disallow inter-VM TPS. Once inter-VM TPS is disallowed, available free memory might drop which further can lead to increased ballooning and swapping. If increased ballooning and swapping activity is observed along with noticeable performance issues, more physical memory can be added on the host or the memory load on the host can be reduced.
To monitor the stats - Run esxtop(1) command:
How can I enable or disable salting for multiple ESXi hosts?
To enable or disable salting for multiple ESXi hosts. Refer to the attached powercli script. This script allows toggling pshare salting for update releases.
Usage
.\pshare-salting.ps1 -s -> Enables pshare salting.
.\pshare-salting.ps1 -o -> Turn offs pshare salting and falls back to default TPS behavior.
I have recently installed VMWare to use Kali Linux on it but upon reaching the login page I wasn't able to type my username/password, it wasn't taking any keyboard input (even with a virtual keyboard)I tried enabling virtual printers but that didn't help
The MyTechZone tab at the top of the home page helps you better navigate the 100's of assets on this site. You need to login to enable it. You don't need to create another ID, we use your existing Customer Connect credentials.
My understanding is that VMMs such as VMware's ESXi Server maintain shadow page tables to map virtual page addresses of guest operating systems directly to machine (hardware) addresses. I've been told that shadow page tables are then used directly by the processor's paging hardware to allow memory accesses in the VM to execute without translation overhead.
Here is what I can tell. Please correct me if I am wrong.Shadow page table is created and maintained by Hypervisor/VMM. It is the table which contains guest virtual addresses and machine physical addresses. Imagine without shadow page table, to get into machine physical address we have to first get virtual address then walk through the OS(guest) page table to get guest physical address, then we need to convert guest physical address into machine physical address. So here is what happening, see how one guest virtual address get translated into machine physical address under the senario of shadow page table:
First physical processor will see the virutal address, and its destination is to get machine physical address. The first thingit do is trying to look at TLB(Translation look aside buffer) if theentry is in TLB we are now get the machine address. This is the mostsimple case which we called a TLB hit case. There is no performanceissue at all. It will run in what ever call a native speed.
If there is no entry in TLB, the processor will do a page table walk in shadow page table. Assuming that there is acorresponding mapping(Guest VA to Machine Physical address), theprocessor will insert the value in TLB then restart the executionand we are good to go this case. This is one other good case. It maytake around 10 cycle to do a look up in shadow page table, soperformance wise we dont have to worry much.
Processor is doing a look up in shadow page table and it could not find the entry. Well in this case as the look up is privilege there will be a fault. The VMM(Virtual Machine Monitor) will look up into the guest page table to resolve the issue. This case is a little complicate. Any way when the VMM walk through the guest page table there will be two possibilities.
3a8082e126