I'm not understanding creating Windows multiple-volume AMIs correctly.

[Jimster]

Hi,

Error here will lie between keyboard and chair... I am obviously failing to grasp a fundamental volume idea, happy to be enlightened.

Task is to spin up a W2016 Server AMI with multiple drives, C & S, and provision image with software on both drives.  We then want to spin up EC2 instances which have both drives, but in different sizes.  So some might be c: 30, s: 30, some might need to be c: 500. s: 1000.

There will also be cases where they want SQL server images done with 4,5 or 6 drives - I guess the concept is the same; adding an xvdc, xvdd, etc. block and formatting it as described below.

To achieve this in Packer image, I am using:

{
    "builders": [{
        "type":                 "amazon-ebs",
        "vpc_id":               "vpc-****************",
        "subnet_id":            "subnet-****************",
        "security_group_id":    "sg-****************",
        "region":               "us-east-1",
        "source_ami":           "ami-client-w2016-image",
        "ami_name":             "2disks-from-packer-test-{{timestamp}}",
        "iam_instance_profile": "****************",


        "launch_block_device_mappings": [{
            "device_name": "/dev/sda1",
            "volume_size": 30,
            "volume_type": "gp2",
            "delete_on_termination": true
        },
        {
            "device_name": "xvdb",
            "volume_size": 30,
            "volume_type": "gp2",
            "delete_on_termination": true    
        }],

To enable Windows to provsion both drives in the image, I am using the follwing Powershell:

        {
            "type":         "powershell",
            "script":       "./setup_two_drive_names_c_and_s.ps1"      
        },

Where the above ps1 is:

# Do volume config of the two drives
write-host "Setting up drives..."
Initialize-Disk -Number 1 -PartitionStyle "MBR"
New-Partition -DiskNumber 1 -UseMaximumSize -IsActive -AssignDriveLetter
Format-Volume -DriveLetter d -Confirm:$FALSE
label c: "volume1"
label d: "volume2"
Set-Partition -DriveLetter D -NewDriveLetter S

There is also the small matter of preserving the letter mappings in windows when the EC2 instance launces via

 C:\ProgramData\Amazon\EC2-Windows\Launch\Config\DriveLetterMappingConfig.json

However, all this works fine when we spin up EC2 instances with 30 and 30.  It works for >2 drives as long as the TF is the same size as the image.  The EC2 instances come online with 30 GB C: and 30 GB S: drives.  However, if we change the drive sizes in Terraform, to provision 100 and 100, we get the C: with 100GB but the S: has only 30GB formatted and the remainder of the volume is unformatted partition, when we check with Windows disk manager on the instance.  This is the problem - the S: drive is staying the same as the AMI image size.  I would have thought we could just created the Packer AMI sizes with the smallest we need to provision the software, and let Terraform build out the actual capacity sizes based on use-cases for each server function.  We are also encrypting the volumes (I can't access that code from here right now).

What am I failing to grasp?  Are the TF EC2 instances re-using the same volumes Packer is creating somehow?  I can see how formatting them in the image when they are 30GB is different than getting a 100GB formatted drive, but we can't provision the S: drive in Packer unless it's formatted.  

Any advice welcome.

[dragon788]

In the past there have been some interesting quirks in Packer and Vagrant in Windows where the uploaded script file may not get updated between multiple steps, and formatting via unattend.xml or first boot/login scripts is tough to test across various providers and disk types.

If you attach the volumes on boot and use the user data script to check the disks for uninitialized volumes and then initialize and format those would it accomplish the same goal?

[James Jennett]

Hey Dragon,

I was doing that on other builds but then, we have to wait for the instance to come online before the extra drives are formatted and then wait while the software gets installed to the various drives.

If we provision the drives and install the software in Packer, then the EC2 instance is ready much quicker as the stuff we need is baked into the image.

JJ

On Fri, 8 Nov 2019 at 18:28, dragon788 <drag...@gmail.com> wrote:

In the past there have been some interesting quirks in Packer and Vagrant in Windows where the uploaded script file may not get updated between multiple steps, and formatting via unattend.xml or first boot/login scripts is tough to test across various providers and disk types.

If you attach the volumes on boot and use the user data script to check the disks for uninitialized volumes and then initialize and format those would it accomplish the same goal?

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.

GitHub Issues: https://github.com/mitchellh/packer/issues
IRC: #packer-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Packer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to packer-tool...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/packer-tool/7f77bcdb-9001-4f5a-9303-6a270a3d7021%40googlegroups.com.