ML
    • Recent
    • Categories
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    HyperV Partitioning

    IT Discussion
    8
    25
    2.4k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      StorageNinja Vendor @travisdh1
      last edited by StorageNinja

      @travisdh1 said in HyperV Partitioning:

      You expect Microsoft to do things rationally, or correctly? That'd be a nice change of pace.

      My point is that things in the IO path go through that VM. They didn't want to write a full IO driver stack for Hyper-V so they have the VM for that. Compute/Memory doesn't go through it (that I know of), but network and disk IO do. (Otherwise Perfmon wouldn't work as a monitoring solution on the host).

      AFAIK only ESXi uses a microkernel that has a fully isolated management agent plane (It's actually just a busybox shell).

      ObsolesceO 1 Reply Last reply Reply Quote 0
      • black3dynamiteB
        black3dynamite @travisdh1
        last edited by

        @travisdh1 said in HyperV Partitioning:

        @storageninja said in HyperV Partitioning:

        @tim_g said in HyperV Partitioning:

        Windows Server runs on top, and every VM runs beside it. The only thing Windows Server can do, is manage the VMs using various components.
        The Hyper-V Hypervisor is only 20 MB. It runs in memory. Not sure what you mean by "god awful footprint"?

        If that VM is a pure control plane, then I can reboot or patch it without impacting network or storage IO on the other VMs in the same way I can restart management agents on ESXi or KVM right? If Hyper-V is handling the network and storage traffic 100% then surely it must have its own driver stack, and not be dependent on the management VM for these functions, right?
        Unless this has changed, you lost every VM on a host from a simple reboot of the management VM previously.

        You expect Microsoft to do things rationally, or correctly? That'd be a nice change of pace.

        XenServer does the same thing too.

        travisdh1T 1 Reply Last reply Reply Quote 2
        • travisdh1T
          travisdh1 @black3dynamite
          last edited by

          @black3dynamite said in HyperV Partitioning:

          @travisdh1 said in HyperV Partitioning:

          @storageninja said in HyperV Partitioning:

          @tim_g said in HyperV Partitioning:

          Windows Server runs on top, and every VM runs beside it. The only thing Windows Server can do, is manage the VMs using various components.
          The Hyper-V Hypervisor is only 20 MB. It runs in memory. Not sure what you mean by "god awful footprint"?

          If that VM is a pure control plane, then I can reboot or patch it without impacting network or storage IO on the other VMs in the same way I can restart management agents on ESXi or KVM right? If Hyper-V is handling the network and storage traffic 100% then surely it must have its own driver stack, and not be dependent on the management VM for these functions, right?
          Unless this has changed, you lost every VM on a host from a simple reboot of the management VM previously.

          You expect Microsoft to do things rationally, or correctly? That'd be a nice change of pace.

          XenServer does the same thing too.

          Where did I claim that anyone gets it right? Looks to me like only ESXi get's it with this particular issue.

          1 Reply Last reply Reply Quote 0
          • DustinB3403D
            DustinB3403
            last edited by

            You can restart the toolstack on XenServer and not interfere with the daily operations of the VM's.

            So um. . .

            1 Reply Last reply Reply Quote 0
            • ObsolesceO
              Obsolesce @StorageNinja
              last edited by Obsolesce

              @storageninja said in HyperV Partitioning:

              My point is that things in the IO path go through that VM. They didn't want to write a full IO driver stack for Hyper-V so they have the VM for that. Compute/Memory doesn't go through it (that I know of), but network and disk IO do. (Otherwise Perfmon wouldn't work as a monitoring solution on the host).

              I think you have some misconceptions or misunderstandings regarding the Hyper-V architecture and components... or Hyper-V stack...

              This is not true at all, as it actually depends on the OS running in a VM.

              Operating systems that already have the integration components baked into their kernel (Enlightened VMs) use their own Hypercalls to communicate directly to the hypervisor, then to the physical hardware.

              Only for non-supporeted (older) operating systems, does the "parent partition" intercept the VM communication, emulating Hypercalls. In this case, there are performance degradations as the management OS needs to work as a bridge to allow the VM to access the hardware.

              To note, this is why it's important for VMs to be running with the latest IC version.

              1 Reply Last reply Reply Quote 0
              • 1
              • 2
              • 2 / 2
              • First post
                Last post