It all very much depends on the exact situation.
Situation 1: The VM was turned off.
You mentioned that the specific VM can be turned on and off. I'm going to assume turning it off through the control panel shuts the VM down, meaning all RAM will be wiped.
In such a case, if the attacker could have turned the VM on and logged in, they could have stolen the password manager data base. This database is encrypted with either a master password or a key file.
In case of a master password, it depends on the exact configuration of the Key-Derivation Function set before the database was compromised. With sufficiently strict parameters, and a reasonably long password/passphrase, brute-forcing the database is nigh-impossible.
If a keyfile was used, and the keyfile was never transferred to the VM while the attacker had access, then it is also virtually impossible for the attacker to attack the database.
This is generally the best-case scenario.
Situation 2: The VM was used during the time of compromise.
In this case, the attacker could have actively attempted to gather passwords through your password manager, by waiting for the required key material (password/passphrase, keyfile, etc.) to be supplied.
While this is certainly theoretically possible, it would require the attacker to specifically target password managers. It's not possible for me to say whether or not they did.
Are password managers less secure than memorized passwords?
Password managers are designed to protect against a different kind of attack. In the vast majority of cases, the servers where a password is used are hacked, and hashes of these passwords are stolen. In such a case, a long and completely random password generated by a password manager is virtually impossible to crack, while a humanly rememberable password is magnitudes easier to crack by comparison. Sure, there are passwords/passphrases that are extremely difficult to crack, but they pale in comparison to
In the case of the machine where a password is stored being compromised, the password database is still encrypted, meaning that an attacker either needs to wait for the password database to be decrypted or they need to crack the master password themselves.
In comparison, if one were to use humanly memorable passwords, an attacker would need to wait for a user to enter the password manually. Depending on your habits (re-using passwords, using patterns for passwords, etc.), this means an attacker only needs to grab a few passwords to have access to your accounts.
In this situation, the humanly memorable passwords that follow all guidelines (all unique, strong passwords) and are never used while the machine is compromised, would fare better than a password manager.
However, such situations are much less frequent than hashes being stolen via e.g. a SQL Injection vulnerability. As such, it is still best-practice to use a password manager.
How should you react now?
First of all, change all your passwords of all accounts in the compromised database. Enable Multi-Factor Authentication for any service that offers is. Even with a cracked password, an attacker cannot compromise your account if the second or third factor is not compromised.
Finally, don't host your password manager in the VM. If it is at all possible, host a password manager locally and configure them to auto-type keystrokes instead. This means an attacker never has direct access to your password manager database. Sure, they would still have access to any password you enter, but that is unavoidable if your VM is compromised.