none
Snapshots & Performance

    Pergunta

  • http://technet.microsoft.com/en-us/library/dd560637(v=ws.10).aspx says "The presence of a virtual machine snapshot reduces the disk performance of the virtual machine." I also saw some threads here that explain the more snapshots you have the more IOs need to propagate through the snapshots. Does that mean the current state only contains the changes since the last snapshot, snapshot n only contains the changes of snapshot n-1, etc? So if a file has not changed for a while hyper-v needs to traverse the through the snapshots backwards?

    If the above is true I understand the why snapshots give a performance penalty. On the other hand, this is not how I expected a snapshot to work. I figured the current state has all the files without having to travers back. If I now take a snapshot hyper-v will compare the last snapshot with the current state and store the difference. So if you want to restore a snapshot you start from the beginning and apply all the differences stored in all the snapshots up to the snapshot that you want to restore. That is a bit more time consuming but it should keep the current state at max performance.

    Maybe everything works as just mentioned in the previous paragraph. If so then why do snapshots make things slower? Because the consume disk space, can cause fragmentation and slow downs? If so I would assume this is quite minimal if not neglectable if you have plenty of free space on your HD.

    Can somebody shed some light on this.

    terça-feira, 20 de março de 2012 22:36

Respostas

  • SANs generally implement VSS Hardware Snapshot Providers.  This thread is about the other kind of snaphot, the Hypervisor snapshot.  This is not the same as a VSS snapshot.  The blog link provided by Vincent describes Hypervisor snapshots .... almost. 

    Let's assume the simple case of a VM with one VHD.  Further, let's say it's a fixed VHD.  In the article, Ben Armstrong gets it right about the pase resume memory etc, but then it goes astray describing the VHD and the AVHD files.  Writes are quiesced, and an AVHD is created and linked to the parent (in our case the VHD). When IO resumes, new writes go to the AVHD.  Reads are still served from the VHD as well as the data written to the AVD.  The important thing is that while the hypervisor snapshot is in place, no writes happen on the parent; they happen in the newly created avhd child.

    Now an avhd is simply a differencing disk.  It's a dynamic VHD.  It has a block allocation table.  When you write, if a block hasn't already been created and mapped in the child, it will be.  When you read, it checks if the block is in the child and if not it still goes back and reads from the parent.  When you remove the hypervisor snapshot, the metadata files are removed and then eventually the child is merged with the parent.  You can have chains, with the newest snapshot being a new child at the end of the chain.  Yes, there is a performance penalty when a hypervisor snapshot is in place.  While it is in place however, you know that the blocks in the parent will not change, and you can open the parent to read.  It's not perfect, and it's not aware of the filesystem on luns inside it, but just like differencing disks there are edge cases where it could be useful.   You absolutely do not want to treat hypervisor snapshots like you would VSS snapshots; only use the minimum necessary and for as short of time as possible. 

    • Sugerido como Resposta VR38DETTMVP quinta-feira, 22 de março de 2012 09:21
    • Marcado como Resposta hfaun quinta-feira, 22 de março de 2012 14:51
    quinta-feira, 22 de março de 2012 03:44
  • Hi,
     
    Does that mean the current state only contains the changes since the last snapshot
    >> You are partly right. When you take a snapshot, the system create a new differencing disk for each virtual hard disk and hook it up to the virtual machine. So, all changes after the snapshot will be saved in the snapshot.
     
    By the way, you can check the following guide. The description here is detailed.
     
     

    Vincent Hu

    TechNet Community Support

    • Marcado como Resposta hfaun quarta-feira, 21 de março de 2012 03:54
    quarta-feira, 21 de março de 2012 03:25

Todas as Respostas

  • Hi,
     
    Does that mean the current state only contains the changes since the last snapshot
    >> You are partly right. When you take a snapshot, the system create a new differencing disk for each virtual hard disk and hook it up to the virtual machine. So, all changes after the snapshot will be saved in the snapshot.
     
    By the way, you can check the following guide. The description here is detailed.
     
     

    Vincent Hu

    TechNet Community Support

    • Marcado como Resposta hfaun quarta-feira, 21 de março de 2012 03:54
    quarta-feira, 21 de março de 2012 03:25
  • Thanks for the link. I read through it and the posts. Considering the concept of these snapshots I can easily see why you don't want to use them in a production system. I am sure there must be some reason for the way it is done but from a user's/administrator's point of view it does seem like a good approach. Anyways, thanks.
    quarta-feira, 21 de março de 2012 03:54
  • Thanks for the link. I read through it and the posts. Considering the concept of these snapshots I can easily see why you don't want to use them in a production system. I am sure there must be some reason for the way it is done but from a user's/administrator's point of view it does seem like a good approach. Anyways, thanks.

    Not all snapshots are created equal! If you have a SAN with a properly implemented snapshots (under "properly implemented" I assume Redirect-on-Write architecture *and* working VSS hardware storage provider so OS could talk to snapshot engine, think about NetApp FAS2xxx here) then you're fine. Snapshots don't eat CPU cycles, visible space on volume and system is NOT in redirected mode after snapshot is taken and mounted. If you have a DAS or a bad SAN then MS would use default Copy-on-Write (read - dog slow architecture) built-in snapshot engine and volume will last in redirected mode for a long time. This is what you probably don't want to see. In a nutshell: get rid of a DAS, use proper SAN and test snapshot implementation BEFORE putting it into production (and submitting P.O. of course). Simple :)

    Hope this helped :)

    -nismo

    quarta-feira, 21 de março de 2012 22:34
  • SANs generally implement VSS Hardware Snapshot Providers.  This thread is about the other kind of snaphot, the Hypervisor snapshot.  This is not the same as a VSS snapshot.  The blog link provided by Vincent describes Hypervisor snapshots .... almost. 

    Let's assume the simple case of a VM with one VHD.  Further, let's say it's a fixed VHD.  In the article, Ben Armstrong gets it right about the pase resume memory etc, but then it goes astray describing the VHD and the AVHD files.  Writes are quiesced, and an AVHD is created and linked to the parent (in our case the VHD). When IO resumes, new writes go to the AVHD.  Reads are still served from the VHD as well as the data written to the AVD.  The important thing is that while the hypervisor snapshot is in place, no writes happen on the parent; they happen in the newly created avhd child.

    Now an avhd is simply a differencing disk.  It's a dynamic VHD.  It has a block allocation table.  When you write, if a block hasn't already been created and mapped in the child, it will be.  When you read, it checks if the block is in the child and if not it still goes back and reads from the parent.  When you remove the hypervisor snapshot, the metadata files are removed and then eventually the child is merged with the parent.  You can have chains, with the newest snapshot being a new child at the end of the chain.  Yes, there is a performance penalty when a hypervisor snapshot is in place.  While it is in place however, you know that the blocks in the parent will not change, and you can open the parent to read.  It's not perfect, and it's not aware of the filesystem on luns inside it, but just like differencing disks there are edge cases where it could be useful.   You absolutely do not want to treat hypervisor snapshots like you would VSS snapshots; only use the minimum necessary and for as short of time as possible. 

    • Sugerido como Resposta VR38DETTMVP quinta-feira, 22 de março de 2012 09:21
    • Marcado como Resposta hfaun quinta-feira, 22 de março de 2012 14:51
    quinta-feira, 22 de março de 2012 03:44
  • SANs generally implement VSS Hardware Snapshot Providers.  This thread is about the other kind of snaphot, the Hypervisor snapshot.  This is not the same as a VSS snapshot.  The blog link provided by Vincent describes Hypervisor snapshots .... almost. 

    Let's assume the simple case of a VM with one VHD.  Further, let's say it's a fixed VHD.  In the article, Ben Armstrong gets it right about the pase resume memory etc, but then it goes astray describing the VHD and the AVHD files.  Writes are quiesced, and an AVHD is created and linked to the parent (in our case the VHD). When IO resumes, new writes go to the AVHD.  Reads are still served from the VHD as well as the data written to the AVD.  The important thing is that while the hypervisor snapshot is in place, no writes happen on the parent; they happen in the newly created avhd child.

    Now an avhd is simply a differencing disk.  It's a dynamic VHD.  It has a block allocation table.  When you write, if a block hasn't already been created and mapped in the child, it will be.  When you read, it checks if the block is in the child and if not it still goes back and reads from the parent.  When you remove the hypervisor snapshot, the metadata files are removed and then eventually the child is merged with the parent.  You can have chains, with the newest snapshot being a new child at the end of the chain.  Yes, there is a performance penalty when a hypervisor snapshot is in place.  While it is in place however, you know that the blocks in the parent will not change, and you can open the parent to read.  It's not perfect, and it's not aware of the filesystem on luns inside it, but just like differencing disks there are edge cases where it could be useful.   You absolutely do not want to treat hypervisor snapshots like you would VSS snapshots; only use the minimum necessary and for as short of time as possible. 

    Makes sense! Thank you very much for your detailed clarification. Indeed I've looked @ the wrong place...

    -nismo

    quinta-feira, 22 de março de 2012 09:22