Add in Lab name to the module

[kilasuit]

This would allow me to create a Lab called "Default 2012R2" and then also a "Default 2008R2" lab config and then in Start-LabConfig & Start-Lab just call an additional -LabName Parameter which would then look for configurations in a sub Folder of the Configuration directory.

This could be useful for Lab Configurations for SharePoint 2013/2016 or SQL 2012/2014/2016 etc and would be easier work with.

I would expect this would work off of the Lability EnvironmentPrefix attribute for the Sub Folder & Lab Name Creation and that would be my suggested implementation method

[iainbrighton]

@kilasuit This was discussed initially in issue #43. This will definately be needed if we ever progress onto AWS and/or Azure publishing.

Whatever we choose to implement has to be implemented in such a way that if a Lab name is not defined in .psd1 file, things still work. I have committed to being able to use an existing DSC configuration document without any modifications.

[iainbrighton]

@kilasuit Just thinking this through. If we were to extended the configuration data with a lab name, then we could infer this without a -LabName parameter. For example:

@{
    NonNodeData = @{
        Lability = @{
            LabName = 'My Test Lab';
        }
    }
}

This would allow us to infer the subdirectory without having to specify the -LabName parameter (I still think that you should be able to override it if required).

An alternative could be to search recursively from the Configuration directory root? This might cause issues if you have multiple configurations with the same VM names though..

Thoughts?

[kilasuit]

I think that perhaps combining LabName & EnvironmentPrefix would be a good safe bet.

This I would then think would end up something like the below

@{
    NonNodeData = @{
        Lability = @{
            LabName = 'My Test Lab';
            EnvironmentPrefix = 'TLG-';
        }
    }
}

And then VM's would be named

My Test Lab\TLG-VMName

This then would give the below file paths of

C:\Lability\Configurations\My Test Lab\TLG-VMName.mof
C:\Lability\Configurations\My Test Lab\TLG-VMName.meta.mof
C:\Lability\VMVirtualHardDisks\My Test Lab\TLG-VMName.vhdx

That way it shouldn't cause filename or path issues for the files

[iainbrighton]

This sounds logical. Wouldn't/shouldn't the file paths be:

C:\Lability\Configurations\My Test Lab\VMName.mof
C:\Lability\Configurations\My Test Lab\VMName.meta.mof
C:\Lability\VMVirtualHardDisks\My Test Lab\TLG-VMName.vhdx

The .mof files wouldn't/shouldn't be prefixed as that's a Lability "thing"?

[kilasuit]

Yes - that makes sense especially when stored in the right lab folders so there would be no need to prefix the mof files.
Vhdx & the resulting Vm's however should still have this in my opinion.

[iainbrighton]

@kilasuit Whilst the EnvironmentName, EnvironmentPrefix and EnvironmentSuffix keywords have been implemented, placing the VHD files into the EnvironmentName subdirectory hasn't yet been implemented. I'll start work on this (why doesn't Hyper-V support folders for VMs?!).

[iainbrighton]

Looping @rikhepworth in here as implementing virtual switches with the prefix/suffix has also been raised. Here are my initial/random thoughts:

• We would need to provide a way to opt in/out of whatever we implement
• We could only prefix virtual switches if they're Internal or Private.
  • If a vSwitch is marked as External we'll leave it alone
    • In fact, can you have multiple vSwitches bound to one physical NIC?
• Would we need to be able to specify an IP address on an Internal or External vSwitch?
  • This could be used for VM communication without relying on DHCP/APIPA.
  • If so, how could we support multiple switches?
• Seemingly, only a single NAT configuration can be deployed on Win 10/Server 2016
  • Wish in Add Server 2016 NAT support #44
  • Therefore, multiple virtual switches couldn't work 😭.

Anything else that I've missed?!

[rikhepworth]

@iainbrighton whilst you can only have one netnat the internal address prefix can be set so that you can span multiple address ranges.
We use 192.168.224.0/19 for our Lability project, allowing us to have 20 /24 subnets from .224.0/24 up to .254.0/24
Our thoughts were that we would define a switch and address range for an environment. If the subnet was already in use we'd fail the deployment. If not, we'd create the switch, assign the IP and deploy the VMs. That said, we are able to apply constraints in our config (defining max and min network values, for example) that you can't really do within Lability.
I guess, if you want to get clever, you could check for the netnat, assess whether the network range for the switch falls within the range for the netnat, etc. If you wanted to go as far as creating a new netnat, I'd advise bailing if one already exists.

I'd strongly urge against external switches. They are a real pain if you don't have a physical adapter. Netnat would be my preference as a one-size-fits all approach. The only time I'd agree to an external switch is if I had to allow inbound traffic to the virtual network and I didn't want to define any nat mappings on the host.

You don't set the IP on the virtual switch, but on the adapter created on the host (which includes the name of the vswitch in brackets so you can find it).

My thoughts:

1. I need to be able to specify a set virtual switch even if the environment/VMs have a prefix specified.
2. I think excluding 'external' virtual switches is a reasonable constraint.
3. If a new virtual switch is created, the IP address on the resulting NIC on the host should get an IP address if I specify one in the config, and not if not (windows will give it a 169.x.x.x address in that case)
4. I would treat netnat as something that is part of the Host config, not part of an Environment. I'd create it as part of the lab host configuration and allow the internaladdressprefix to be defined in the hostdefault. Potentially, (maybe a setting), I would block the creation of network addresses and ranges that don't sit within the netnat.
5. If I specify a private switch we don't need to check any of the above...