Vagrant keeping my disks awake

[Adrian Wallaschek]

I assembled a nice machine for use with Vagrant

<bragging>Threadripper 12c, 128GB RAM, 4 NVMe, some SATA SSD and ... two classic magnetic disks</bragging>

The idea is that the work happens on the NVMe SSDs, Storage is on SATA SSDs and Archive/Backup is on the magnetic disks. I believe this kind of makes sense ;-). In normal operation the archive disks (magnetic) are assume to power down and stay this way until the get explicitely accessed.

So far for the theory.

Vagrant shows a behaviour that strikes me, though:

My archive disks go to sleep and power off after a while, that is they stop the spindles. Good!

The moment I run the next vagrant command, e.g. a

vagrant ssh

on one of the disks, the vagrant command blocks, I hear the HDDs (both) starting the spindles and once they (acoustically) appear started, I see the vagrant command continuing its mission. This is ... confusing and annoying.

It appears to me as if vagrant is checking the drives for some content or config before doing anything. Once the HDDs are active, there is no mentionable delay with vagrant anymore, but it insist on starting the drives before doing anything.

Could anybody please tell me, what activity makes Vagrant talk to my HDDs and possibly how I could avoid this. Unless I can do something about it, my only way to get rid of this misbehaviour would be:

1. unmount the drives when not needed (not a bad idea, pretty much emotet-safe).

2. mount the drives to a directory rather than a drive-letter (untested)

3. configure the drives to not go to power-safe (by noise and ecology not my first choice)

I really hope for a suggestions that looks better that this!

Help?

Thanks in advance!

Adrian

[Adrian Wallaschek]

 It is late and I am tired. Sorry for not putting this first:

• Operating system is Windows 10
• I install vagrant 2.2.7 using Chocolatey (including the vmware utils)
• VMware Workstation 15.5 latest (also via Chocolatey)
• I use the paid provider for VMware vagrant_desktop Version 2.0.3

All of this works like a charme, minus the sleep-deprevation for my HDDs.

What can I do about it?

 

[Alvaro Miranda Aguilera]

What about you mount in the guest some remote filesystem ??

in that way will be accessed only when needed.

without much information about how your pc looks like, boot disk, filesystem layout, will be a lot of guessing.

So i would take the simple route and use a filesystem to the VM.

Alvaro.

[Adrian Wallaschek]

It is not a matter of a VM. The magnetic disks are just in the host. They are not used by any VM nor VMware nor Vagrant. Right now, my MP3 collection is on them. The whole Vagrant and VM stuff ist on SSD.

But wenn I run "vagrant ssh" (e.g.) in the Powershell, then it first spins up the HDDs. They are not in the PATH, they do not contain Software, nothing.

I beliebe from some weird reason vagrant when starting enumerate the disks in the system and checks for - maybe - config files or so on each one of them.

I would think that somebody would know or recognize this behaviour and give me a hint on how to inhibit that. (config directive, whatever).

So to make it clear: even if no VM is running .... this happens when running vagrant: it wakes up my HDDs (Y: and Z:, while VMware and Vagrant are on V: and system is on C: each on separate physical volumes).

To explain it in more detail:

C: is a mirror set of two NVMe SSDs (2x 1TB)

V: is a striped volume of two other NVMe SSDs (2x2TB)

some other SATA SSDs (4 pcs, unrelated) have own drive letters

Y: is a magnetic disk (8TB)

Z: is a magnetic disk (ditto)

If on V: I run vagrant whatever, the command spins up Y: and Z:, not only that ... it also waits for the spin up to complete, which is boring me.

Does that kind of explain the problem better?

[Jeff Bonhag]

Hi Adrian,

Thanks for the detailed report (nice system btw!). I'd recommend running Vagrant with the debug flag, like `vagrant ssh --debug`. That will show a detailed log of all the commands Vagrant is running. It could be that something like a PowerShell script or some other host introspection is accessing the magnetic disks.

Please let us know if you find anything interesting!

Cheers,

Jeff

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/vagrant/issues
Discuss: https://discuss.hashicorp.com/c/vagrant/24
---
You received this message because you are subscribed to the Google Groups "Vagrant" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vagrant-up+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vagrant-up/95992818-0bd1-41b4-843c-4fdc0b1f0132%40googlegroups.com.

[Adrian Wallaschek]

Hi again.

Just an update:

• the debug log showed nothing I could identify as relevant
• as I suspected some code to traverse the drive-letters in search of something, whatever, I unmounted the HDD from Y: and Z: and mounted them onto some directory mount point on the C: drive. Thus I assured that no reasonable data-access would hit the disks. I am pretty sure that Vagrant does not traverse directories. The log would show and it would be "mind-blowingly" slow. Effect? None? Still the drives spin up when vagrant comes to play.

I take a few consequences from this:

• I stopped suspecting the root-cache in the vagrant-area
• I begin to suspect Windows. For some reason, likely the powershell or some system call spins up the drives.

I will not try to debug Windows. It is by far easier to configure the drives to not go to power-save mode early. This is slightly frustrating but pursueing the matter further? With Microsoft? I do not hate myself enough to do that.

So thanks for the advice, but I have to take the easy way out.

Best regards,

Adrian