It seems, c5d.9xlarge and c5d.18xlarge are excluded by intention, already grayed out in AWS instance start console. Other providers (RH) enable them too. Thanks

-----Ursprüngliche Nachricht----- Von: CentOS-virt centos-virt-bounces@centos.org Im Auftrag von Nico Kadel-Garcia Gesendet: Samstag, 14. Juli 2018 14:22 An: Discussion about the virtualization on CentOS centos-virt@centos.org Betreff: Re: [CentOS-virt] AWS c5d.9/18xlarge instances not supported

On Sat, Jul 14, 2018 at 7:41 AM, Jens-Uwe Schluessler jens-uwe.schluessler@tu-dresden.de wrote:

Hi,

why are larger AWS instances c5d.9xlarge and c5d.18xlarge (NVMe SSD attached) NOT supported by Centos7 AMI,

It wouldn't be the first time. I had problems with the i3 instances when they first came out, and I've been dealing with kernel/hardware incompatibilities with Linux kernels since.... 2000. New hardware, and even new virtualization toolkits that interact with both the supporting hardware and the virtualization layer, can have startling interactions. That's why testing is so critical.

while smaller instances (e.g. c5d.4xlarge) are supported?

Also regular c5.9/18xlarge are supported.

See above. Also, the base CentOS 7 3.10.0 kernel is becoming a bit dated: it's 5 years old now. If you have time: can you set up a smaller instance, do kernel updates on top of a CentOs 7 AMI, and see if *that* AMI is compatible with the new instances? Might make for an interesting test and get you a working AMI. _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt

On Sat, Jul 14, 2018 at 3:11 PM, Henry Finucane h.finucane@gmail.com wrote:

On Sat, Jul 14, 2018 at 5:22 AM Nico Kadel-Garcia nkadel@gmail.com wrote:

...

See above. Also, the base CentOS 7 3.10.0 kernel is becoming a bit dated: it's 5 years old now. If you have time: can you set up a smaller instance, do kernel updates on top of a CentOs 7 AMI, and see if *that* AMI is compatible with the new instances? Might make for an interesting test and get you a working AMI.

I did this with CentOS 6 at some point, and it's worth noting that you'll have to build your own AMI from scratch, you can't just update the existing AMI- the base AMI's lack of support "taints" derived ones.

There Are Ways(tm). One of my favorite is to link a LiveDVD image to the VM built from the messed up or out of date OS image, mount the storage for the messy host, and do the updates on a chroot cage to *that*. In this case, there instances of the same class, just different sizes, that are apparently tested and approved. I'd stage a build to one of the approved instance types and do the updates *there*, then take a snapshot.

I used packer's chroot builder, it was pretty reasonable and you can find examples online to help you get started.

Heh. I wrote tools that did something like this for hardware testing, creating a base tarball image much like "mock" does and applying it to new hadware configurations from DHCP and kickstart, and even one that could be downloaded and run to upgrade from a local tarball. That was in... 2000, and was used on roughly 20,000 systems that year for an OS update. It's still faster than most virtualization "disk image" based clones from a golden image.