Thanks Rajani, I checked that the agent is running on SSVM:
root@s-1-VM:~# service cloud status
CloudStack cloud service (type=secstorage) is running: process id: 3887

When I run




















*SSVM health check, it outputs:First DNS server is  192.168.0.100PING
192.168.0.100 (192.168.0.100): 56 data bytes64 bytes from 192.168.0.22
<http://192.168.0.22>: Destination Host UnreachableVr HL TOS  Len   ID Flg
off TTL Pro  cks      Src      Dst Data 4  5  00 5400 4859   0 0040  40  01
f05f 192.168.0.22  192.168.0.100 64 bytes from 192.168.0.22
<http://192.168.0.22>: Destination Host UnreachableVr HL TOS  Len   ID Flg
off TTL Pro  cks      Src      Dst Data 4  5  00 5400 4959   0 0040  40  01
ef5f 192.168.0.22  192.168.0.100 --- 192.168.0.100 ping statistics ---2
packets transmitted, 0 packets received, 100% packet lossWARNING: cannot
ping DNS serverroute followsKernel IP routing tableDestination
Gateway         Genmask         Flags Metric Ref    Use
Iface169.254.0.0     0.0.0.0         255.255.0.0     U     0      0
0 eth0192.168.0.0     0.0.0.0         255.255.255.0   U     0      0
0 eth1192.168.0.0     0.0.0.0         255.255.255.0   U     0      0
0 eth2192.168.0.0     0.0.0.0         255.255.255.0   U     0      0
0 eth3================================================*
*Actually although DNS server is set to *
*192.168.0.100( as it is the internal NIC of the Management Server), there
are nothing on it. Just /etc/hosts mappings of hostnames and IPs.*


*Could this DNS IP settings a problem? Or I should set it to 8.8.8.8, but
this VMs are just private and not visible to the outside, confused here.*


*cheers,Dan*

2014-11-10 22:14 GMT-06:00 Rajani Karuturi <[email protected]>:

> Did you check if the agent is running on SSVM?
> This wiki might help.
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSVM,+templates,+Secondary+storage+troubleshooting
>
> ~Rajani
>
> On Tue, Nov 11, 2014 at 5:04 AM, Dan Dong <[email protected]> wrote:
>
> > Some more info, on SSVM I can see the following routes, there is route
> > there, so why SSVM(eth2: 192.168.0.134) could not contact Management
> > Server(192.168.0.100)? Can someone help here? Thanks
> > root@s-1-VM:~# ip route
> > default via 192.168.0.100 dev eth2
> > 169.254.0.0/16 dev eth0  proto kernel  scope link  src 169.254.1.47
> > 172.20.10.0/24 via 192.168.0.100 dev eth1
> > 172.20.10.30 via 192.168.0.100 dev eth1
> > 192.168.0.0/24 dev eth1  proto kernel  scope link  src 192.168.0.22
> > 192.168.0.0/24 dev eth2  proto kernel  scope link  src 192.168.0.134
> > 192.168.0.0/24 dev eth3  proto kernel  scope link  src 192.168.0.25
> >
> >
> > 2014-11-10 15:12 GMT-06:00 Dan Dong <[email protected]>:
> >
> > > Hi, All,
> > >   When debugging why my ISOs could not be registered, I found when I
> > > logged into SSVM, I could not even ping the Management Server, although
> > > they are both in the 192.168.0.0/24 network, so of course could not
> ping
> > > outside world. Here are my simple network settings of my
> > cloud(1Management
> > > Server + 1 KVM hypervisor):
> > >
> > > 1. Management server have 2 NICs:
> > >            em2 pointing outside with 10.0.0.100/24
> > >            em1 pointing inside with 192.168.0.100/24 (also serves as
> DNS
> > > and Gateway of the cloud)
> > > 2. One KVM hypervisor which has 1 NIC: em1 with 192.168.0.101/24
> > > 3. VMs created on KVM hypervisor will sit on the same network of
> > > 192.168.0.0/24
> > >
> > > The weird thing is that I can access the internet from the KVM
> hypervisor
> > > as NAT is enabled on the Management Server, but for the SSVM(IP of
> eth2:
> > > 192.168.0.89) running on it, it could not even see the Management
> > > Server(192.168.0.100 on em1). Should one manually re-configure routing
> > > tables on the SSVM to solve this problem or it is caused by the initial
> > > network design of the cloud? Thanks!
> > >
> > > Cheers,
> > > Dan
> > >
> > >
> >
>

Reply via email to