0

Hyper-V has two folders 'Virtual Hard Disks' and 'Virtual Machines', the first stores the virtual disks themselves and the latter stores settings, snapshots, etc.

Is there's benefit of storing these two folders on separate SSD drives to:

  1. Increase performance - reduce chances of disk related IO bottleneck

  2. Increasing individual SSD life longevity - 'Virtual Machines' folder stores .VMRS files which are equal to the amount of configured RAM on the guest OS, so this folder should get hit harder with disk writes on RAM intensive guest OSs and degrade the SSD faster.

AlexVPerl
  • 217
  • 2
  • 9

1 Answers1

2

THere really is none. As you can see in the case that if you use a cluster setup, they all live in the same cluster shared volume.

If the VM impacts performance you have a SERIOUS problem on the performance. Same with SSD longevity.

TomTom
  • 51,649
  • 7
  • 54
  • 136
  • Thank you for your response. In the cluster scenario I see your point. What are your thoughts on this for a single Hyper V instance? – AlexVPerl Oct 22 '21 at 13:47
  • The same. There is no real impact. Get a proper SSD - and you are done. The system partition of the VM is neither large nor creating a lot of writes. – TomTom Oct 22 '21 at 13:50
  • I agree w/ you on that for .VHDX files for most use cases unless guest OS is a file server or is doing lots writes & deletes. But .VMRS files store the running state of VMs, they are basically a RAM snapshot of the VM. In a busy VM RAM is constantly being rewritten, so .VMRS files should strain & wear out the SSD much more than .VHDX files. – AlexVPerl Oct 22 '21 at 14:28
  • 1
    Ah, NO. .VMRS are not updated constantly with RAM information. I am not sure where you got this ridiculous idea from. They are updated only when the running state of the VM is recorded. There is no constant write activity there. The file is allocated when the VM starts, then it is written do when the VM is put into a dormant state - THAT IS IT. WHY you think that it would update the file constantly? RAM has 50+GB/S throughput - NO SSD SETUP COMES CLOSE. Also what would be the use, as outside of controlled moves.... vms restart after a power failure. – TomTom Oct 22 '21 at 14:32
  • As such, in normal operations, .VRMS do not create any significant write load and your argument thus is not valid. – TomTom Oct 22 '21 at 14:32
  • Ok, I follow your train of thought. Looking at modified dates of .VRMS files I believe you are correct, since the timestamps are 1-2 days behind. I wasn't implying that VRMS files are updated in real time (it would be a bottleneck), rather a frequent snapshot, but it appears its not that frequent at all. The question then becomes if the .VRMS update is full or differential, I want to assume differential but if it's full then my argument still stands. – AlexVPerl Oct 22 '21 at 14:50
  • The .VRMS files contain the dynamic part of the VM configuration. As long as a VM is running, it should basically not have any change in that at all. Hence there is no load implication from them, hence there is nothing gained from moving them away from the discs of the VM. – TomTom Oct 22 '21 at 14:52
  • I think its more frequent than you believe. I'm checking one of the servers, and .VMRS files are 1-2 days old max, these VMs were not restarted for weeks nor modified in any way. With that said, I have to agree with you regarding performance - there would be nothing to gain by storing them on separate SSD. But not yet convinced about the SSD wear, it would depend if .VRMS updates are full or differential. – AlexVPerl Oct 22 '21 at 15:07
  • Nope, it will not. See, any SSD storage that you should use should already be heavy duty and thus the VMRS files should not add anything to this that is measurable. 5 Writes Per Day is what you should have on the SSD side. – TomTom Oct 22 '21 at 15:21
  • I appreciate you engaging in this discussion. Let's consider a full 2TB drive, with general assumption 50% are .VHDX files and another 50% are .VRMS files (of course .VRMS portion could be even higher based on assigned RAM), at 5 writes per day you're looking at at least 5 TBW per day. Lets say average enterprise SSD is rated at 1400 TBW, that's just 280 days to wear out that drive. I think there's something to be said about possibly moving .VRMS files to a mechanical HDD. – AlexVPerl Oct 26 '21 at 19:37
  • Yeah, that happens when you buy crap drives not up for the task. Sit down, do your homework and get drives that ARE RATED FOR 5 WRITES PER DAY. Done. Your "average enterprise SSD" is just a crap cheap drive that is not MEANT for high intensity workloads. Get a proper drive, you get 3 WPD for 5 years. Get a tool appropriate for the job. Or get a 4tb drive and allocate 50% as reserve. – TomTom Oct 26 '21 at 19:46
  • You also make a logical total non argument - the level I would fire a trainee for. We established that the VRMS file has a lot LESS writes than the VHD. Then you go on assuming that they do the same writes to justify how fast the crappy drives burn out. If anything, the .VRMS files will LENGTHEN the usability of the drives, as they have hardly any write (you do not restart vm's all the time under normal use) and thus... use up SLOWER. But essentially, get proper high end intensive write drives. – TomTom Oct 26 '21 at 19:48
  • Oh, and another thing - have you ever bothered trying running a number of VM's from a small number (not even one) HDD? Here is a hint: All that nice IO disappears faster than fog on a sunny day. You literally need dozens of HDD to even fail at coming close to the IO. When you do patching, you will wait forever for anything to happen as the discs will be busy moving their heads. Been there, done that. Never again. Only with a VERY large SSD cache in the cluster, which, incidentally, is 5 Writes per day - and I go all SSD in 2022 when we do the next rework. All NVME acually. – TomTom Oct 26 '21 at 19:53
  • You contradict yourself in above comments, first you claim that VRMS writes are infrequent and then you go on to say that putting them on HDD will kill performance. With VHDX files on a mechanical drives, yes performance is horrible. For VRMS files I don't think it would matter much since they're infrequent snapshots which likely happen asynchronously. Also, you wrongfully assume that everyone's workload & environment is same as yours. You speak only from point of view of a large data center that can afford of arrays of $4000 SSD drives. What about startups/SMEs with limited budget? – AlexVPerl Oct 26 '21 at 23:44
  • Your way of thinking is completely closed off to creative solutions by saying there’s only one “right” way to solve a problem. It’s also a bit ignorant to say that if you’re not using $4000 drives - your hardware setup is crap. Facebook, in its early days was run entirely on clusters of self-built servers using overclocked AMD chips in consumer grade motherboards that were open air without cases. By your way of thinking they would have “had” to use only enterprise hardware or nothing. Could they afford it back then? No. Would they survive if they spent most of their budget on it? Likely not. – AlexVPerl Oct 26 '21 at 23:44
  • I’m just saying that it’s not one size fits all and that there are other creative solutions out there. Also, you completely overlook workloads where single VM can use large amounts of RAM (256-512GB), for example a VM running a high-performance in-memory database or cache. Multiple daily VRMS writes of that size would certainly strain an SSD. You also make the mistake of repeatedly assuming that VRMS files are only written to during restarts – wrong. You should read up MS’s documentation or check one of the servers, you’ll see they’re updated more frequently. – AlexVPerl Oct 26 '21 at 23:44