Is TLS secure against VM reset attacks?
No, TLS is not secure against VM reset attacks. There are at least two attacks that are made possible by VM reset attacks, off the top of my head:


AES-GCM nonces are typically generated deterministically from the message counter value. If you set the snap shot prior to the local peer sending a plain text message that will change after resetting to the snap shot, you will have a severe nonce reuse vulnerability. As specified in RFC 5288, the 64 bit explicit nonce that is sent per packet MAY equal the message counter. The current TLS 1.3 draft removes the explicit nonce and replaces it with the implicit message counter xor:ed with the static IV values that were derived from the master secret. The same nonce generation is specified in the chacha20-poly1305 draft, which consequently has the same vulnerability. The traditional CBC cipher suites would be less vulnerable, in particular if used in encrypt-then-mac mode. Edit: In practice, the VM engine might be implemented to automatically close all TCP connections when suspended, and not necessarily reconnect when resumed after a reset. This might help to make the attack less practical against normal TLS connections directly over TCP. TLS over other types of channels and DTLS over UDP might be a different story.
Session master secrets are supposed to be discarded after any fatal alert corresponding to the session, such as failures to verify the finished messages. An attacker that is able to reset the local peer would obviously be able to circumvent this. This means e.g. that an attacker might attempt to perform session resumptions using the session id belonging to another peer, even after an initial failure. Such attacks against the session state do not depend on in which state the VM engine leaves the network stack when resetting to a snapshot.