I was just reading this topic on the VMTN community. In short, a second vswp file gets created during a VMotion. As the starter of this topic noticed it could lead to not being able to VMotion VMs if you don’t have enough free disk space on your VMFS volume.
One of my UK colleagues, David Burgess, jumped in and explained what is happening during the VMotion and why this temporary vswp file is being created. Read it, it’s useful info:
- It is only used if the target is under memory pressure. It is thin provisioned so even though it looks the size of the memory it should have very little impact on the free space of the VMFS.
- The other thing is that the temp swap will only be used for activity as the machine transitions so should not grow to the size of the memory. If you “du” the file systems you should see the the blocks being consumed. Engineers think this should be tops 400M, if it is used at all. By pressured we mean the amount of memory free is low. That will not deny the VM to VMotion unless we can’t allocate enough reserved memory (this is zero by default). Once the transition is complete the VM reverts to the original swap file and the temp is deleted.
Take a look at the screenshot David uploaded, the bottom two vswp files are the ones created during the VMotion and as you can see are consuming 0 blocks.
John Yarborough says
Hi Duncan! Sorry to dig up an old topic. I have a question I think is somewhat related though. I noticed one of my VM’s was using a fair amount of VSWP and in the past, I’ve typically just rebooted the guest and things return to normal. I was thinking though, shouldn’t a vMotion take whatever was swapped on the source host and put it in RAM on the target host, assuming there are no resource limits or memory contention on the target? I just tried this and it seems that the same amount of VSWP is in use on the target host as there was on the source. Is this expected? Is the only way to force VSWP back into memory something drastic like a reboot of the guest? Thanks!