HyperVDsc icon indicating copy to clipboard operation
HyperVDsc copied to clipboard

VMHyperV: Split VM, disk and network configuration

Open iainbrighton opened this issue 8 years ago • 5 comments

The xVMHyperV resource is getting pretty cumbersome. I think we probably need to separate the VM definition, its virtual NIC(s) and VHDs into separate resources. Whilst #31 and #33 request the abililty to attach multiple VHDs and multiple NICs, there are plenty of other properties that could be managed too. Is it worth leaving the current xVMHyperV implementation and creating 3 new resources (obviously the names are up for discussion and we could drop the 'x' prefix!)?:

  • xVM
    • Creates a VM without any disks or NICs
  • xVMDisk
    • Manages and attaches VHD(s) assigned to a VM.
    • xVHD resource would still be used for creating VHD(X)s.
  • xVMNetworkAdapter
    • Manages and attaches NIC(s) and MAC(s) assigned to a VM.

The xVMHyperV resource could be flagged as deprecated in the readme and via a warning message for the forseeable future. Or the this could be swapped for a composite resource (with the existing schema) that manages a VM and attaches a single disk/NIC?

Thoughts @HemantMahawar @TravisEz13 @KarolKaczmarek ?

iainbrighton avatar Jan 19 '16 22:01 iainbrighton

@iainbrighton @TravisEz13 @KarolKaczmarek ... I almost agree :) Adding the 2 new resources for VMDisks and VMNetworkAdapter would be good that deals with advance scenarios around those on a VM. I am not so sure about creating a new one for VM. If the intent is to support creating a VM without disk or NIC, we can change (non-breaking change) the schema of xVMHyperV resource to have VhdPath as write instead of required property.

HemantMahawar avatar Feb 01 '16 21:02 HemantMahawar

@HemantMahawar @KarolKaczmarek @TravisEz13 The only issue I see with leaving xVMHyper as-is is that you could get into a right mess by specifying a VHD and/or NIC in xVMHyperV and then trying to attach a primary disk or NIC with another resource.

However, even with a new 'VM' resource I guess there would be nothing stopping you still doing that with xVMHyperV either. I guess there's no accounting for stupidity?!

We can at least start with a resource for attaching additional disks/NICs and come back to the xVMHyperV?

iainbrighton avatar Feb 03 '16 22:02 iainbrighton

Oh! I just noticed this thread! :) I started a similar discussion https://github.com/PowerShell/xHyper-V/issues/47.

I can push my cVMNetworkAdapter, cVMNetworkAdapterVLAN, and cVMIPAddress to this repo if you are OK with it.

rchaganti avatar Feb 16 '16 13:02 rchaganti

I really think at least the cVMNetworkAdapterVLAN functionality needs to be included.

randomchance avatar Apr 28 '16 18:04 randomchance

xVMNetworkAdapter is now pushed to this repo. #53 is waiting to be merged if everyone agrees.

rchaganti avatar May 12 '16 06:05 rchaganti