Change:
// Inside the instance, the mountpoint always looks like /dev/xvdX (?) hostDevice := "/dev/xvd" + string(mountDevice) <del> // In the EC2 API, it is sometimes is /dev/sdX and sometimes /dev/xvdX // We are running on the node here, so we check if /dev/xvda exists to determine this </del> <ins> // We are using xvd names (so we are HVM only) // See http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/device_naming.html </ins> ec2Device := "/dev/xvd" + string(mountDevice) <del> if _, err := os.Stat("/dev/xvda"); os.IsNotExist(err) { ec2Device = "/dev/sd" + string(mountDevice) } </del> // attachEnded is set to true if the attach operation completed // (successfully or not)

Discussion:
I am having trouble on my AWS 1.3.0beta0 cluster to attach EBS with the controller-manager based attacher. There problem is here: This is failing as the kube-controller-manager is running in a pod via kubelet manifests. I think if you have a cluster with different instance types mixed you ran into trouble as well, as the device names will be either (sdX or xvdX) and the cluster will do it based on the state of the master (controller-manager). My work around for now is to enable a host mount of for the controller manager. But this need to be addressed at some point. Is there any way we get the correct name from the AWS api? I think it's depending on the kernel version if it is xvdX or sdX. Am I right on this? A more ugly solution could be to annotate the node during registration, if it's has or device names maybe you can help me get a proper solution for this. I am happy to contribute a PR
I have just found , I think we could get this information from AWS:
That code is supposed to check, but it is quite possible I got it backwards looking at it. Also I agree that the logic is going to be problematic anyway with mixed instance types etc if we've moved attachment to KCM. What AMI are you using? I may have just been "lucky" so far in the AMIs I've used, in that the heuristics have worked correctly. Also, if you have time, would be great to know: /dev/ looks like on one of the problematic nodes (i.e. in particular we have /dev/sda and/or /dev/xvda)? is the output of the describe-images command for that AMI (particularly if it is private)? I like the describe-images approach!

I'm marking this as 1.3 P1 (sorry as for now my working hypothesis is that this was introduced when we moved disk attachment to KCM (I believe previously the kubelet did it, but want to double-check)
I tried to get a such environments with CoreOS amis: (all eu-west1) vtype is PV vtype is HVM The describe instances returns different rootdevicenames: But if I ssh into the two instances, the devices are called the same for both: I think we have to somehow signal the devicename from the Kubelet to the KCM to solve this properly. My understanding is to get the sdX names we have to use an pretty old kernel. Maybe it'a good idea to change the default behaviour, see PR . So fallback to '/dev/xvdX'
I don't see any indication that this is a regression. I am kicking it out of milestone 1.3. Explain how it is a regression or otherwise super-important to get it back on the milestone.
It is a regression: volume mounting is broken on AWS. My believe is that it happens because we have moved volume mounting to KCM, and/or KCM runs in a container. Between those two, volume mounting just doesn't work right now.