Issues with CloudLab OpenStack Tutorial

[Dave Krauss]

Hi all,

I’m new to CloubLabs and am having a couple of issues. I’m working through the CloudLab OpenStack Tutorial (my URN is urn:publicid:IDN+emulab.net:cloudlab+slice+dkraus0-QV4002 if that helps identify my specific set up.)

First issue is with SSH: it seems like the SSH credentials may not be making into the VM’s that I’m creating? As an example, I am able to SSH to the controller, networkmanager and compute1 VM’s directly from the “list view” on the experiment page. I use a Mac, my SSH key pairs were generated via GENI, I downloaded my private key (from GENI) and it’s on my computer. However, when I try to SSH to the public IP address of a VM I created in OpenStack (the 128.110.155.x IP), the VM always prompts me for a password. Perhaps my public key isn’t being configured in the VM?

Second issue is with allocating floating IP’s to VM’s. I don’t seem to be able to allocate floating IP addresses to more than two VM’s. Is this a limitation I’m encountering, or is there an issue with OpenStack?

Thanks,
Dave Krauss

[David M. Johnson]

On 03/30/15 12:29, Dave Krauss wrote:
> Hi all,
>
> I’m new to CloubLabs and am having a couple of issues. I’m working
> through the CloudLab OpenStack Tutorial (my URN is
> urn:publicid:IDN+emulab.net:cloudlab+slice+dkraus0-QV4002 if that helps
> identify my specific set up.)
>
> First issue is with SSH: it seems like the SSH credentials may not be
> making into the VM’s that I’m creating? As an example, I am able to SSH
> to the controller, networkmanager and compute1 VM’s directly from the
> “list view” on the experiment page. I use a Mac, my SSH key pairs were
> generated via GENI, I downloaded my private key (from GENI) and it’s on
> my computer. However, when I try to SSH to the public IP address of a VM
> I created in OpenStack (the 128.110.155.x IP), the VM always prompts me
> for a password. Perhaps my public key isn’t being configured in the VM?

Hi Dave. Can you point me to an instance where this is happening? If
the VMs are getting an IP address and successfully binding the floating
IP (so you have connectivity), they're probably getting key info too.
I've had some reports about some keys not being liked, but haven't
previously had time to chase it down.

> Second issue is with allocating floating IP’s to VM’s. I don’t seem to
> be able to allocate floating IP addresses to more than two VM’s. Is this
> a limitation I’m encountering, or is there an issue with OpenStack?

Public IPs are a Cloudlab resource you must request. The
Tutorial-OpenStack profile requests 4; 2 get used internally by
OpenStack on openvswitch router interfaces (:(); leaving 2 for the VMs.

> Dave Krauss

David

[David M. Johnson]

On 03/30/15 13:45, David M. Johnson wrote:
> On 03/30/15 12:29, Dave Krauss wrote:
>> Hi all,
>>
>> I’m new to CloubLabs and am having a couple of issues. I’m working
>> through the CloudLab OpenStack Tutorial (my URN is
>> urn:publicid:IDN+emulab.net:cloudlab+slice+dkraus0-QV4002 if that helps
>> identify my specific set up.)
>>
>> First issue is with SSH: it seems like the SSH credentials may not be
>> making into the VM’s that I’m creating? As an example, I am able to SSH
>> to the controller, networkmanager and compute1 VM’s directly from the
>> “list view” on the experiment page. I use a Mac, my SSH key pairs were
>> generated via GENI, I downloaded my private key (from GENI) and it’s on
>> my computer. However, when I try to SSH to the public IP address of a VM
>> I created in OpenStack (the 128.110.155.x IP), the VM always prompts me
>> for a password. Perhaps my public key isn’t being configured in the VM?
>
> Hi Dave. Can you point me to an instance where this is happening? If
> the VMs are getting an IP address and successfully binding the floating
> IP (so you have connectivity), they're probably getting key info too.
> I've had some reports about some keys not being liked, but haven't
> previously had time to chase it down.

Sorry, I see your URN and checked it out. Your public key is being
placed in /root/.ssh/authorized_keys in your instance VM correctly by
the cloud-guest-utils. If you look at that pubkey, does it correspond
to the private key you're trying?

[Dave Krauss]

David,

Thanks for the reply. I'm not sure at all how to log in to the VM to check the ssh key:

* Public IP isn't working (SSH)
* I can't find a device on the 172.16.0.0/12 network to log into either
* I try opening a console on the VM, but I get a "Error: no available console found"

I was able to look at /root/.ssh/authorized_keys on compute1, and I see what looks like a couple of keys for me in there. But, honestly, I don't know enough about ssh to know if a pubkey I'm looking at corresponds with my private key.

Thanks,
Dave

[David M. Johnson]

On 03/30/15 14:04, Dave Krauss wrote:
> David,
>
> Thanks for the reply. I'm not sure at all how to log in to the VM to
> check the ssh key:
>
> * Public IP isn't working (SSH)

Hm, I was able to login as root to 128.110.155.135 using the password in
the tutorial instructions. So it is working; make sure you can login
via root and passwd (see the Profile Instructions for your experiment).

> * I can't find a device on the 172.16.0.0/12 network to log into either

Yes, not from the physical machines hosting your experiment, because the
172.16 network is an EGRE tunnel. If you allocate instances on the
flat-data-net, you should be able to setup routes on the physical
network to let you speak directly to your VMs. The flat-data-net is a
weird one anyway; it basically is just a big shared LAN that any
instance could be hooked onto and runs directly atop the physical
ethernet LAN allocated to your experiment. That physical LAN is private
to your experiment, of course.

> * I try opening a console on the VM, but I get a "Error: no available
> console found"

Yes, you allocated your machines on CloudLab, which only has ARM
machines, which do not provide a VGA head. Thus, no graphical console.
Furthermore, last I looked, OpenStack does not yet allow you to attach
to the serial console, although developers have discussed a proposal for
adding it. With the ARM machines, web console access to the VMs is not
currently possible.

[Dave Krauss]

David,

This must be an SSH thing I don't understand. I can log into 128.110.155.134/5 as root too, which I didn't know before. But, I cannot login as "dkrauss." However, the _opposite_ is true for the controller, networkmanager and compute1. So here are the only things that work:

For controller, networkmanager, compute: dkraus0@ ms02xxx.utah.cloudlab.us
For vm-1, vm-2: root@ 128.110.155.134/5

My userid for the nodes seems to be dkraus0 (not sure if that matters) instead of dkrauss. On the VM's, using root, I was able to look at the /root/.ssh/authorized_keys file, and my public key is there: however, after my public key is "dkrauss." When I look at the same file on the nodes, it contains "dkraus0@ ms02xxx.utah.cloudlab.us" instead of "dkrauss."

If I need to go read up on SSH...let me know...!

Thanks,
Dave

[Jonathon Duerig]

For the controller, networkmanager, and computer, you use the login name
that you are told to use in the CloudLab interface. When you are logged
in, you see this name in the upper-right. Sometimes it isn't the same as
your GENI username because we might add a number to ensure that it is
unique.

If you are ever confused about what to use to log into these physical
machines allocated in your experiment, check the list view and it will
tell you. Any username in your key file is a pure comment. The only
username you can use is the one assigned to you by the system. In this
case, it sounds like dkraus0.

The VMs are instantiated inside and I will have to defer to David on what
the proper way to log into those is.

---
Broad audience or deep message: Pick one.

> --
> You received this message because you are subscribed to the Google Groups "cloudlab-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> cloudlab-user...@googlegroups.com.
> To post to this group, send email to cloudla...@googlegroups.com.
> To view this discussion on the web visithttps://groups.google.com/d/msgid/cloudlab-users/5ec16ccc-270a-4ff1-8f56-58faf2970b43%40googlegroups
> .com.
> For more options, visit https://groups.google.com/d/optout.
>
>

[David M. Johnson]

On 03/30/15 16:13, Dave Krauss wrote:
> David,
>
> This must be an SSH thing I don't understand. I can log into
> 128.110.155.134/5 as root too, which I didn't know before.

This information is in the Profile Instructions -- light blue box on the
status page, above the topology picture.

> But, I cannot login as "dkrauss."

This is expected; we opted not to mirror *all* your Cloudlab account
data into the openstack setup; only your pubkeys get stuffed into it,
and thus into the VMs you create inside the Openstack admin project.

> However, the _opposite_ is true for the controller,
> networkmanager and compute1. So here are the only things that work:

Yep, that's how it's supposed to be. The Openstack physical machines
are part of your Cloudlab experiment, and their environment is tailored
to your experiment (i.e., your user account is there, network
configuration is performed, etc).

> For controller, networkmanager, compute: dkraus0@ ms02xxx.utah.cloudlab.us
> For vm-1, vm-2: root@ 128.110.155.134/5
>
> My userid for the nodes seems to be dkraus0 (not sure if that matters)
> instead of dkrauss. On the VM's, using root, I was able to look at the
> /root/.ssh/authorized_keys file, and my public key is there: however,
> after my public key is "dkrauss." When I look at the same file on the
> nodes, it contains "dkraus0@ ms02xxx.utah.cloudlab.us" instead of "dkrauss."

I'm going to let someone else answer the part about dkrauss/dkraus0 .

> Dave

David

> On Monday, March 30, 2015 at 4:18:02 PM UTC-4, David Johnson wrote:
>
> On 03/30/15 14:04, Dave Krauss wrote:
> > David,
> >
> > Thanks for the reply. I'm not sure at all how to log in to the VM to
> > check the ssh key:
> >
> > * Public IP isn't working (SSH)
>
> Hm, I was able to login as root to 128.110.155.135 using the
> password in
> the tutorial instructions. So it is working; make sure you can login
> via root and passwd (see the Profile Instructions for your experiment).
>
> > * I can't find a device on the 172.16.0.0/12

> <http://172.16.0.0/12> network to log into either

>
> Yes, not from the physical machines hosting your experiment, because
> the
> 172.16 network is an EGRE tunnel. If you allocate instances on the
> flat-data-net, you should be able to setup routes on the physical
> network to let you speak directly to your VMs. The flat-data-net is a
> weird one anyway; it basically is just a big shared LAN that any
> instance could be hooked onto and runs directly atop the physical
> ethernet LAN allocated to your experiment. That physical LAN is
> private
> to your experiment, of course.
>
> > * I try opening a console on the VM, but I get a "Error: no available
> > console found"
>
> Yes, you allocated your machines on CloudLab, which only has ARM
> machines, which do not provide a VGA head. Thus, no graphical console.
> Furthermore, last I looked, OpenStack does not yet allow you to attach
> to the serial console, although developers have discussed a proposal
> for
> adding it. With the ARM machines, web console access to the VMs is not
> currently possible.
>

> --
> You received this message because you are subscribed to the Google
> Groups "cloudlab-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to cloudlab-user...@googlegroups.com

> <mailto:cloudlab-user...@googlegroups.com>.

> To post to this group, send email to cloudla...@googlegroups.com

> <mailto:cloudla...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/cloudlab-users/5ec16ccc-270a-4ff1-8f56-58faf2970b43%40googlegroups.com

> <https://groups.google.com/d/msgid/cloudlab-users/5ec16ccc-270a-4ff1-8f56-58faf2970b43%40googlegroups.com?utm_medium=email&utm_source=footer>.