DanielJGF's Posts

I have looked in the Internet and haven't found an answer to this self posed question: When you extend a VMFS volume across multiple physical disks. Is there some sort of stikiness of the virtual di... See more...
I have looked in the Internet and haven't found an answer to this self posed question: When you extend a VMFS volume across multiple physical disks. Is there some sort of stikiness of the virtual disks with regards to the physical disks, or the volume will behave like a RAID 0 stripe set and will evenly distribute the data among the disks?
Yes, I also tried that flag, same result. esxcli software vib install -v /tmp/somevib.vib -f --no-sig-check [ProfileValidationError] In ImageProfile (Updated) ESXi-8.0.0-20513097-standard, the pay... See more...
Yes, I also tried that flag, same result. esxcli software vib install -v /tmp/somevib.vib -f --no-sig-check [ProfileValidationError] In ImageProfile (Updated) ESXi-8.0.0-20513097-standard, the payload(s) in VIB SOMEVIB does not have sha-256 gunzip checksum. This will prevent VIB security verification and secure boot from functioning properly. Please remove this VIB or please check with your vendor for a replacement of this VIB Please refer to the log file for more details. I am reading contradictory information, but some of this info points at the fact that ©VMWare has totally blocked execution of community supported binaries in ©ESXi 8.0. https://williamlam.com/2015/05/a-docker-container-for-building-custom-esxi-vibs.html  
Thank you very much for your answer. Still, setting the host to CommunitySupported # esxcli software acceptance set --level=CommunitySupported;esxcli software acceptance get # CommunitySupported ... See more...
Thank you very much for your answer. Still, setting the host to CommunitySupported # esxcli software acceptance set --level=CommunitySupported;esxcli software acceptance get # CommunitySupported And setting the VMkernel.Boot.execInstalledOnly to false still results in foreign .vib files being rejected. # esxcli software vib install -v /tmp/somevib.vib -f [ProfileValidationError] In ImageProfile (Updated) ESXi-8.0.0-20513097-standard, the payload(s) in VIB somevib does not have sha-256 gunzip checksum. This will prevent VIB security verification and secure boot from functioning properly. Please remove this VIB or please check with your vendor for a replacement of this VIB Please refer to the log file for more details. Also binaries already installed can't be executed: -sh: ./somevib: Operation not permitted  
It seems that last version of ©ESXi (8.0) does not allow to install nor execute communty supported binaries within the ©ESXi hypervisor OS. According to ©VMWare documentation, it seems that executio... See more...
It seems that last version of ©ESXi (8.0) does not allow to install nor execute communty supported binaries within the ©ESXi hypervisor OS. According to ©VMWare documentation, it seems that execution of binaries not signed by ©VMWare is plainly blocked. https://kb.vmware.com/s/article/76276 Are there any plans to reconsider this limitation?.    
   
There isn't any limitation in speed from part of VMWare. The reason behind slow SCP from/to ESXi over a WAN is a small receiving buffer. This limitation is also present in other SCP/SSH implementatio... See more...
There isn't any limitation in speed from part of VMWare. The reason behind slow SCP from/to ESXi over a WAN is a small receiving buffer. This limitation is also present in other SCP/SSH implementations. As SCP/SSH works over TCP, every time the remote buffer fills, it sends an acknowledgement packet to the sending end. The sending end will not send any new data until the acknowledgement is received. As latency increases the very nature of the TCP protocol combined with such small buffer will result in effective bandwidth being drastically affected. We have written a post on improving effective SCP/SSH speed in VMWare ESXi  along with some easy to implement workarounds As Joerg pointed out mounting the target volume over NFS could be a possible workaround, but whether it works or it is even possible will depend on your network topology.  
https://33hops.com/xsibackup-vmware-esxi-backup.html ©XSIBackup offers a solution working as a service in the ©ESXi Hypervisor, thus it is agnostic of the ©ESXi version and it doesn't need any addit... See more...
https://33hops.com/xsibackup-vmware-esxi-backup.html ©XSIBackup offers a solution working as a service in the ©ESXi Hypervisor, thus it is agnostic of the ©ESXi version and it doesn't need any additional component to do it's work. It can transfer data to local datastores or to any remote file system running ©ESXi or Linux. It features: - Hot backups & replicas - Block level deduplication plus LZJB compression (from Solaris ZFS). - Unlimited restore points - Differential backups. - Zero awareness. - nCurses GUI. - Granular restores. You have a full featured trial version, generally available from the 1st day of the month until the 15th. Once the trial period expires you can still perform manual backups to local datastores.  
Hi, this is Daniel from ©XSIBackup development. We have followed your case here too. We couldn't help much in the beginning as you didn't provide much information, apart from these two lines .... See more...
Hi, this is Daniel from ©XSIBackup development. We have followed your case here too. We couldn't help much in the beginning as you didn't provide much information, apart from these two lines ./xsibackup: eval: line 1: disk0: not found - not sure what this error refers to Backing up virtual disks... The error is not very helpful, that's why we recommended you to debug the script to narrow the problem down. You should keep in mind some basic principles that will for sure help you in the future. - The contents of your VM, no matter whether they are files or programs can't affect the hypervisor functioning. Only in very seldom cases some service that can't be quiesced may delay the snapshot taking phase and end up in a snapshot error. For that to happen, you should be using the --snapshot=doquiesce argument, which was not the case. - In your case, as you were not trying to quiesce the VM, snapshotting the VM couldn't fail, even if you were running an exigent service inside the guest (except for some other reason: lack of space, hardware problem...). You could end up with a VM copy which may not have consistent data (as you weren't quiescing the VM), some of the last data in your I/O buffers could have been partially written if the snapshot request interrupted it being written to disk, but that is a different issue which is not detected at the hypervisor level. - When you convert virtual disks from some other format, you are adding an additional factor that could add some uncertainty, as whether the resulting .vmdk and -flat.vmdk files are fully consistent with what your ESXi version expects to find. You should mention that when requesting help. - In most of the cases, if not all. Any inconsistency in the .vmdk disks can be solved by cloning them to a new file via vmkfstools. - Editing any of the config files with some external editor may render them unusable or inconsistent. - Disk consistency at the VM level can be rapidly checked by: 1/ Making sure the .vmdk files pointed by the .vmx file are present. 2/ Making sure that the .vmdk files point to the right -flat.vmdk files. 3/ Deleting all snapshots and consolidating the VM plus deleting the .vmsd file, which will be automatically generated again next time you switch the VM on. In your case the problem seemed to be originated in the .vmsd file, as its syntax includes the .diskX keyword, where disk is an ordinal related to the existing snapshots. If you are an ©XSIBackup-Free user and need to request help, please do so in our forum at: https://33hops.com/forum/ And remember that all we know is what you let us know, thus please always provide the backup job the full output log and any other relevant circumstance.
The simplest way to overcome this lockdown is to disable the firewall during the SMTP submission process. This might not be suitable for enterprises with stark security requirements, but may be reaso... See more...
The simplest way to overcome this lockdown is to disable the firewall during the SMTP submission process. This might not be suitable for enterprises with stark security requirements, but may be reasonable for some other people, specially if your host is inside a controlled LAN segment. We will launch an update containing that fix in short, just get to the URL https://33hops.com/xsibackup-vmware-esxi-backup.html  in some days to download the new version. Still, you will just be able to perform a basic Vmkfstools backup on ESXi 7.0.0 Update 2020-11-14: ©XSIBackup-DC is fully compatible with ESXi 7.0, current version 1.4.2.4 has been revised and improved to work with ©ESXi 7.0
Solved! Well, I guess this is the proof that there isn't really an intention to block access to data from the shell and that my first approach to the matter was a bit paranoid in the end. Thank... See more...
Solved! Well, I guess this is the proof that there isn't really an intention to block access to data from the shell and that my first approach to the matter was a bit paranoid in the end. Thank you so much!, I was blinded by my own prejudice, I would have wasted a lot more time until I would have eventually returned to read the disk in a right way. Nonetheless, as the song says, it's never Wasted Time, you always learn something along the way.
You are right!. This is definitely the way to go. Ironically this is the first approach I took, nonetheless I think that I forgot that ESXi dd was quite limited and most probably was passing som... See more...
You are right!. This is definitely the way to go. Ironically this is the first approach I took, nonetheless I think that I forgot that ESXi dd was quite limited and most probably was passing some unit abbreviation instead of the block size in bare units. Switching from Linux to ESXi all the time can make you fall in stupid errors.
As per the tests I have performed so far, any attempt to read the device with a block size larger than 1 byte on ESXi 7.0.0 always returned zero. I will perform some more thorough tests and post... See more...
As per the tests I have performed so far, any attempt to read the device with a block size larger than 1 byte on ESXi 7.0.0 always returned zero. I will perform some more thorough tests and post my results, there's always the possibility that I was doing something wrong or I misinterpreted the output.
Thank you for your kind answer Continuum. Yes, I know that. There is in fact an easier way to accomplish the same. Just get a list of the virtual disk extents by running: vmkfstools -t0 name.... See more...
Thank you for your kind answer Continuum. Yes, I know that. There is in fact an easier way to accomplish the same. Just get a list of the virtual disk extents by running: vmkfstools -t0 name.vmdk That will return a list of the extents compounding the Virtual Disk mapped to the offsets in the device. That method has nonetheless a huge caveat. The device is tuned to only allow reading a byte at a time. That makes reading sizes above some MBs something unfeasible, unless you don't mind waiting some hours to read some big chunk of data.
Forget my last comment, it was quite innocent. I revisited the .vh.sf documentation. Was thinking more on some eventual variable to be set in the .vmx file that would prevent the -flat.vmdk files... See more...
Forget my last comment, it was quite innocent. I revisited the .vh.sf documentation. Was thinking more on some eventual variable to be set in the .vmx file that would prevent the -flat.vmdk files from being locked, as the observed behaviour from part of my client would leave a door open to that. I spent some hours playing around with the .vmx files provided by my client, no joy so far. Maybe the VMs that allow access to these files are just behaving in a buggy way themselves. In any case, being this lock something done on purpose, any still open gap would soon be closed as well.
What about releasing the locks before switching the VM on?. If this is to be done in the hearbeat.section, I believe it won't be valid for clustered scenarios, but could very well serve spare ESX... See more...
What about releasing the locks before switching the VM on?. If this is to be done in the hearbeat.section, I believe it won't be valid for clustered scenarios, but could very well serve spare ESXi hosts systems. Also it's worth noting that the physical disks can be read one byte at a time, which is useless for backups, but may be useful for other situations. I was able to get some .vmx files from the VMs that are being backed up as well as the ones that are not. I suspect that some variable in the .vmx file can be the reason why some -flat.vmdk files are not being locked. I will perform a comparative study on this.
Not yet, running vmkfstools on some .vmdk file to then send a SIGSTOP to the process seems too awkward to be taken into consideration, at least to me (update: tried, it didn't work). I will try ... See more...
Not yet, running vmkfstools on some .vmdk file to then send a SIGSTOP to the process seems too awkward to be taken into consideration, at least to me (update: tried, it didn't work). I will try to find out why those files are blocked in a seemingly random way. I will share all that I can find here, nonetheless you seem to have a deeper knowledge of ESXi than I do.
Just some more good arguments on top of the table. I believe whoever is taking this decissions has not thought about it twice, nonetheless he's probably smarter than me; thus he might have though... See more...
Just some more good arguments on top of the table. I believe whoever is taking this decissions has not thought about it twice, nonetheless he's probably smarter than me; thus he might have thought about it thrice, now the thing is that the vast majority of sysadmins will just do it once. Just a curious thing to add: some of our customers who are trying our software on ESXi 7.0.0 report that the blocking doesn't happen everytime. In some cases they are indeed able to access the -flat.vmdk file and back it up.
That's looks like a way to fence off SME's and encourage them to buy a license. Nonetheless not very wise, as can backfire with a drop in the use of Free version. Anyway...
Well probably Veeam has first hand information, or maybe they just observed the same thing. Vmkfstools being able to access those -flat.vmdk files without issue is an indication that the new beh... See more...
Well probably Veeam has first hand information, or maybe they just observed the same thing. Vmkfstools being able to access those -flat.vmdk files without issue is an indication that the new behaviour is there by design. But, why would VMWare do such a nasty thing?, ESXi is in the end an OS.
Sorry to bother you again Continuum, but I believe this to be relevant for the thread. As per our tests and the feedback provided by our users, this blocks on the flat.vmdk files (always when ... See more...
Sorry to bother you again Continuum, but I believe this to be relevant for the thread. As per our tests and the feedback provided by our users, this blocks on the flat.vmdk files (always when the VM is running on a snapshot) observed in ESXi 7.0.0 seem to be random, which is double puzzling. What I mean is that some -flat.vmdk files are read just fine, while others are blocked, this is in the same host and under the exact same circumstances. This opens again the door to believe that it could be a bug instead of intentional, although being intentional would still make sense, some apparently random behaviour points at a possible bug. (*) I deleted my previous post, as it doesn't make sense to offer my opinion on something that I still can't grasp to comprehend.