While Thomas Pornin is correctly pointing out that the only way to trust a host under attack is using fully homomorphic encryption in practice you can try to work around this requirement.
A potential attacker has full control of CPU, memory and disk. So it is not possible to do any calculations on valuable data in a VM that might not be under your control. On the other hand it is often not necessary. If you want to use your VM as a database or storage / backup service the VM never needs access to unencrypted information. You could store files or entries in a database, store hashes of the encrypted files or file names and e.g. sort for file size or retrieve a certain file where the client supplies the file name as a hash value.
Such a scheme limits what you can do with your data but given a good encryption it is impossible for an attacker to steal your data. In the worst case they can modify it, so you need encrypted signatures to prevent tampering of the data.
A popular example is boxcryptor, which uses an encrypted container to store files securely at different cloud providers. Another is duplicity, which allows encrypted backups using rsync and GnuPG.
Encrypting the storage of the VM itself by, e.g. truecrypt or Bitlocker does not increase the security level significantly. It might thwart an attack if the VM is powered off but as soon as you run it the OS needs the key to access the encrypted volume and at that moment a potential attacker can get hold of the key as well.