OSDir


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: advanced networking with public IPs direct to VMs


What type of storage are you using? Zone wide? Or cluster "wide" storage?

On Thu, Jun 7, 2018 at 4:25 AM, Jon Marshall <jms.123@xxxxxxxxxxxxx> wrote:

> Rafael
>
>
> Here is the output as requested -
>
>
>
> mysql> mysql> select * from cloud.storage_pool where removed is null;
> +----+------+--------------------------------------+--------
> -----------+------+----------------+--------+------------+--
> ----------+----------------+--------------+-----------+-----
> ------------+---------------------+---------+-------------+-
> -------+-----------------------+-------+------------+-------
> --+---------------+
> | id | name | uuid                                 | pool_type         |
> port | data_center_id | pod_id | cluster_id | used_bytes | capacity_bytes |
> host_address | user_info | path            | created             | removed
> | update_time | status | storage_provider_name | scope | hypervisor |
> managed | capacity_iops |
> +----+------+--------------------------------------+--------
> -----------+------+----------------+--------+------------+--
> ----------+----------------+--------------+-----------+-----
> ------------+---------------------+---------+-------------+-
> -------+-----------------------+-------+------------+-------
> --+---------------+
> |  1 | ds1  | a234224f-05fb-3f4c-9b0f-c51ebdf9a601 | NetworkFilesystem |
> 2049 |              1 |   NULL |       NULL | 6059720704 |    79133933568 |
> 172.30.5.2   | NULL      | /export/primary | 2018-06-05 13:45:01 | NULL
> | NULL        | Up     | DefaultPrimary        | ZONE  | KVM        |
>  0 |          NULL |
> +----+------+--------------------------------------+--------
> -----------+------+----------------+--------+------------+--
> ----------+----------------+--------------+-----------+-----
> ------------+---------------------+---------+-------------+-
> -------+-----------------------+-------+------------+-------
> --+---------------+
> 1 row in set (0.00 sec)
>
> mysql>
>
> Do you think this problem is related to my NIC/bridge configuration or the
> way I am configuring the zone ?
>
> Jon
> ________________________________
> From: Rafael Weingärtner <rafaelweingartner@xxxxxxxxx>
> Sent: 07 June 2018 06:45
> To: users
> Subject: Re: advanced networking with public IPs direct to VMs
>
> Can you also post the result of:
> select * from cloud.storage_pool where removed is null
>
> On Wed, Jun 6, 2018 at 3:06 PM, Dag Sonstebo <Dag.Sonstebo@xxxxxxxxxxxxx>
> wrote:
>
> > Hi Jon,
> >
> > Still confused where your primary storage pools are – are you sure your
> > hosts are in cluster 1?
> >
> > Quick question just to make sure - assuming management/storage is on the
> > same NIC when I setup basic networking the physical network has the
> > management and guest icons already there and I just edit the KVM labels.
> If
> > I am running storage over management do I need to drag the storage icon
> to
> > the physical network and use the same KVM label (cloudbr0) as the
> > management or does CS automatically just use the management NIC ie. I
> would
> > only need to drag the storage icon across in basic setup if I wanted it
> on
> > a different NIC/IP subnet ?  (hope that makes sense !)
> >
> > >> I would do both – set up your 2/3 physical networks, name isn’t that
> > important – but then drag the traffic types to the correct one and make
> > sure the labels are correct.
> > Regards,
> > Dag Sonstebo
> > Cloud Architect
> > ShapeBlue
> >
> > On 06/06/2018, 12:39, "Jon Marshall" <jms.123@xxxxxxxxxxxxx> wrote:
> >
> >     Dag
> >
> >
> >     Do you mean  check the pools with "Infrastructure -> Primary Storage"
> > and "Infrastructure -> Secondary Storage" within the UI ?
> >
> >
> >     If so Primary Storage has a state of UP, secondary storage does not
> > show a state as such so not sure where else to check it ?
> >
> >
> >     Rerun of the command -
> >
> >     mysql> select * from cloud.storage_pool where cluster_id = 1;
> >     Empty set (0.00 sec)
> >
> >     mysql>
> >
> >     I think it is something to do with my zone creation rather than the
> > NIC, bridge setup although I can post those if needed.
> >
> >     I may try to setup just the 2 NIC solution you mentioned although as
> I
> > say I had the same issue with that ie. host goes to "Altert" state and
> same
> > error messages.  The only time I can get it to go to "Down" state is when
> > it is all on the single NIC.
> >
> >     Quick question just to make sure - assuming management/storage is on
> > the same NIC when I setup basic networking the physical network has the
> > management and guest icons already there and I just edit the KVM labels.
> If
> > I am running storage over management do I need to drag the storage icon
> to
> > the physical network and use the same KVM label (cloudbr0) as the
> > management or does CS automatically just use the management NIC ie. I
> would
> > only need to drag the storage icon across in basic setup if I wanted it
> on
> > a different NIC/IP subnet ?  (hope that makes sense !)
> >
> >     On the plus side I have been at this for so long now and done so many
> > rebuilds I could do it in my sleep now 😊
> >
> >
> >     ________________________________
> >     From: Dag Sonstebo <Dag.Sonstebo@xxxxxxxxxxxxx>
> >     Sent: 06 June 2018 12:28
> >     To: users@xxxxxxxxxxxxxxxxxxxxx
> >     Subject: Re: advanced networking with public IPs direct to VMs
> >
> >     Looks OK to me Jon.
> >
> >     The one thing that throws me is your storage pools – can you rerun
> > your query: select * from cloud.storage_pool where cluster_id = 1;
> >
> >     Do the pools show up as online in the CloudStack GUI?
> >
> >     Regards,
> >     Dag Sonstebo
> >     Cloud Architect
> >     ShapeBlue
> >
> >     On 06/06/2018, 12:08, "Jon Marshall" <jms.123@xxxxxxxxxxxxx> wrote:
> >
> >         Don't know whether this helps or not but I logged into the SSVM
> > and ran an ifconfig -
> >
> >
> >         eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> >                 inet 169.254.3.35  netmask 255.255.0.0  broadcast
> > 169.254.255.255
> >                 ether 0e:00:a9:fe:03:23  txqueuelen 1000  (Ethernet)
> >                 RX packets 141  bytes 20249 (19.7 KiB)
> >                 RX errors 0  dropped 0  overruns 0  frame 0
> >                 TX packets 108  bytes 16287 (15.9 KiB)
> >                 TX errors 0  dropped 0 overruns 0  carrier 0  collisions
> 0
> >
> >         eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> >                 inet 172.30.3.34  netmask 255.255.255.192  broadcast
> > 172.30.3.63
> >                 ether 1e:00:3b:00:00:05  txqueuelen 1000  (Ethernet)
> >                 RX packets 56722  bytes 4953133 (4.7 MiB)
> >                 RX errors 0  dropped 44573  overruns 0  frame 0
> >                 TX packets 11224  bytes 1234932 (1.1 MiB)
> >                 TX errors 0  dropped 0 overruns 0  carrier 0  collisions
> 0
> >
> >         eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> >                 inet 172.30.4.86  netmask 255.255.255.128  broadcast
> > 172.30.4.127
> >                 ether 1e:00:d9:00:00:53  txqueuelen 1000  (Ethernet)
> >                 RX packets 366191  bytes 435300557 (415.1 MiB)
> >                 RX errors 0  dropped 39456  overruns 0  frame 0
> >                 TX packets 145065  bytes 7978602 (7.6 MiB)
> >                 TX errors 0  dropped 0 overruns 0  carrier 0  collisions
> 0
> >
> >         eth3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> >                 inet 172.30.5.14  netmask 255.255.255.240  broadcast
> > 172.30.5.15
> >                 ether 1e:00:cb:00:00:1a  txqueuelen 1000  (Ethernet)
> >                 RX packets 132440  bytes 426362982 (406.6 MiB)
> >                 RX errors 0  dropped 39446  overruns 0  frame 0
> >                 TX packets 67443  bytes 423670834 (404.0 MiB)
> >                 TX errors 0  dropped 0 overruns 0  carrier 0  collisions
> 0
> >
> >         lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
> >                 inet 127.0.0.1  netmask 255.0.0.0
> >                 loop  txqueuelen 1  (Local Loopback)
> >                 RX packets 18  bytes 1440 (1.4 KiB)
> >                 RX errors 0  dropped 0  overruns 0  frame 0
> >                 TX packets 18  bytes 1440 (1.4 KiB)
> >                 TX errors 0  dropped 0 overruns 0  carrier 0  collisions
> 0
> >
> >
> >         so it has interfaces in both the management and the storage
> > subnets (as well as guest).
> >
> >
> >
> >         ________________________________
> >         From: Jon Marshall <jms.123@xxxxxxxxxxxxx>
> >         Sent: 06 June 2018 11:08
> >         To: users@xxxxxxxxxxxxxxxxxxxxx
> >         Subject: Re: advanced networking with public IPs direct to VMs
> >
> >         Hi Rafael
> >
> >
> >         Thanks for the help, really appreciate it.
> >
> >
> >         So rerunning that command with all servers up -
> >
> >
> >
> >         mysql> select * from cloud.storage_pool where cluster_id = 1 and
> > removed is null;
> >         Empty set (0.00 sec)
> >
> >         mysql>
> >
> >
> >         As for the storage IP no I'm not setting it to be the management
> > IP when I setup the zone but the output of the SQL command suggests that
> is
> > what has happened.
> >
> >         As I said to Dag I am using a different subnet for storage ie.
> >
> >         172.30.3.0/26  - management subnet
> >         172.30.4.0/25 -  guest VM subnet
> >         172.30.5.0/28 - storage
> >
> >         the NFS server IP is 172.30.5.2
> >
> >         each compute node has 3 NICs with an IP from each subnet (i am
> > assuming the management node only needs an IP in the management network
> ?)
> >
> >         When I add the zone in the UI I have one physical network with
> > management (cloudbr0), guest (cloudbr1) and storage (cloudbr2).
> >         When I fill in the storage traffic page I use the range
> > 172.16.5.10 - 14 as free IPs as I exclude the ones already allocated to
> the
> > compute nodes and the NFS server.
> >
> >         I think maybe I am doing something wrong in the UI setup but it
> is
> > not obvious to me what it is.
> >
> >         What I might try today unless you want me to keep the setup I
> have
> > for more outputs is to go back to 2 NICs, one for storage/management and
> > one for guest VMs.
> >
> >         I think with the 2 NICs setup the mistake I made last time when
> > adding the zone was to assume storage would just run over management so I
> > did not drag and drop the storage icon and assign it to cloudbr0 as with
> > the management which I think is what I should do ?
> >
> >
> >
> >
> >
> >         ________________________________
> >         From: Rafael Weingärtner <rafaelweingartner@xxxxxxxxx>
> >         Sent: 06 June 2018 10:54
> >         To: users
> >         Subject: Re: advanced networking with public IPs direct to VMs
> >
> >         Jon, do not panic we are here to help you :)
> >         So, I might have mistyped the SQL query. You you use select *
> from
> >         cloud.storage_pool where cluster_id = 1 and removed is not null
> ",
> > you are
> >         listing the storage pools removed. Therefore, the right query
> > would be "
> >         select * from cloud.storage_pool where cluster_id = 1 and removed
> > is null "
> >
> >         There is also something else I do not understand. You are setting
> > the
> >         storage IP in the management subnet? I am not sure if you should
> > be doing
> >         like this. Normally, I set all my storages (primary[when working
> > with NFS]
> >         and secondary) to IPs in the storage subnet.
> >
> >         On Wed, Jun 6, 2018 at 6:49 AM, Dag Sonstebo <
> > Dag.Sonstebo@xxxxxxxxxxxxx>
> >         wrote:
> >
> >         > Hi John,
> >         >
> >         > I’m late to this thread and have possibly missed some things –
> > but a
> >         > couple of observations:
> >         >
> >         > “When I add the zone and get to the storage web page I exclude
> > the IPs
> >         > already used for the compute node NICs and the NFS server
> > itself. …..”
> >         > “So the range is 172.30.5.1 -> 15 and the range I fill in is
> > 172.30.5.10
> >         > -> 172.30.5.14.”
> >         >
> >         > I think you may have some confusion around the use of the
> > storage network.
> >         > The important part here is to understand this is for *secondary
> > storage*
> >         > use only – it has nothing to do with primary storage. This
> means
> > this
> >         > storage network needs to be accessible to the SSVM, to the
> > hypervisors, and
> >         > secondary storage NFS pools needs to be accessible on this
> > network.
> >         >
> >         > The important part – this also means you *can not use the same
> > IP ranges
> >         > for management and storage networks* - doing so means you will
> > have issues
> >         > where effectively both hypervisors and SSVM can see the same
> > subnet on two
> >         > NICs – and you end up in a routing black hole.
> >         >
> >         > So – you need to either:
> >         >
> >         > 1) Use different IP subnets on management and storage, or
> >         > 2) preferably just simplify your setup – stop using a secondary
> > storage
> >         > network altogether and just allow secondary storage to use the
> > management
> >         > network (which is default). Unless you have a very high I/O
> > environment in
> >         > production you are just adding complexity by running separate
> > management
> >         > and storage.
> >         >
> >         > Regards,
> >         > Dag Sonstebo
> >         > Cloud Architect
> >         > ShapeBlue
> >         >
> >         > On 06/06/2018, 10:18, "Jon Marshall" <jms.123@xxxxxxxxxxxxx>
> > wrote:
> >         >
> >         >     I will disconnect the host this morning and test but before
> > I do that
> >         > I ran this command when all hosts are up -
> >         >
> >         >
> >         >
> >         >
> >         >
> >         >      select * from cloud.host;
> >         >     +----+-----------------+------
> ------------------------------
> >         > --+--------+--------------------+--------------------+------
> >         > -----------+---------------------+--------------------+-----
> >         > ------------+---------------------+----------------------+--
> >         > ---------------------+-------------------+------------+-----
> >         > --------------+-----------------+--------------------+------
> >         > ------+----------------+--------+-------------+------+------
> >         > -+-------------------------------------+---------+----------
> >         > -------+--------------------+------------+----------+-------
> >         > ---+--------+------------+--------------+-------------------
> >         > --------------------------------------------+-----------+---
> >         > ----+-------------+------------+----------------+-----------
> >         > ----------+---------------------+---------+--------------+--
> >         > --------------+-------+-------------+--------------+
> >         >     | id | name            | uuid
> >  | status
> >         > | type               | private_ip_address | private_netmask |
> >         > private_mac_address | storage_ip_address | storage_netmask |
> >         > storage_mac_address | storage_ip_address_2 |
> > storage_mac_address_2 |
> >         > storage_netmask_2 | cluster_id | public_ip_address |
> > public_netmask  |
> >         > public_mac_address | proxy_port | data_center_id | pod_id |
> > cpu_sockets |
> >         > cpus | speed | url                                 | fs_type |
> >         > hypervisor_type | hypervisor_version | ram        | resource |
> > version  |
> >         > parent | total_size | capabilities | guid
> >         >                         | available | setup | dom0_memory |
> > last_ping  |
> >         > mgmt_server_id | disconnected        | created             |
> > removed |
> >         > update_count | resource_state | owner | lastUpdated |
> > engine_state |
> >         >     +----+-----------------+------
> ------------------------------
> >         > --+--------+--------------------+--------------------+------
> >         > -----------+---------------------+--------------------+-----
> >         > ------------+---------------------+----------------------+--
> >         > ---------------------+-------------------+------------+-----
> >         > --------------+-----------------+--------------------+------
> >         > ------+----------------+--------+-------------+------+------
> >         > -+-------------------------------------+---------+----------
> >         > -------+--------------------+------------+----------+-------
> >         > ---+--------+------------+--------------+-------------------
> >         > --------------------------------------------+-----------+---
> >         > ----+-------------+------------+----------------+-----------
> >         > ----------+---------------------+---------+--------------+--
> >         > --------------+-------+-------------+--------------+
> >         >     |  1 | dcp-cscn1.local | d97b930c-ab5f-4b7d-9243-
> eabd60012284
> > | Up
> >         >  | Routing            | 172.30.3.3         | 255.255.255.192 |
> >         > 00:22:19:92:4e:34   | 172.30.3.3         | 255.255.255.192 |
> >         > 00:22:19:92:4e:34   | NULL                 | NULL
> >   | NULL
> >         >             |          1 | 172.30.4.3        | 255.255.255.128
> |
> >         > 00:22:19:92:4e:35  |       NULL |              1 |      1 |
> >      1 |
> >         >   2 |  2999 | iqn.1994-05.com.redhat:fa437fb0c023 | NULL    |
> > KVM
> >         >      | NULL               | 7510159360 | NULL     | 4.11.0.0 |
> > NULL   |
> >         >    NULL | hvm,snapshot | 9f2b15cb-1b75-321b-bf59-f83e7a5e8efb-
> > LibvirtComputingResource
> >         > |         1 |     0 |           0 | 1492390408 |
>  146457912294 |
> >         > 2018-06-05 14:09:22 | 2018-06-05 13:44:33 | NULL    |
> > 4 |
> >         > Enabled        | NULL  | NULL        | Disabled     |
> >         >     |  2 | v-2-VM          | ce1f4594-2b4f-4b2b-a239-
> 3f5e2c2215b0
> > | Up
> >         >  | ConsoleProxy       | 172.30.3.49        | 255.255.255.192 |
> >         > 1e:00:80:00:00:14   | 172.30.3.49        | 255.255.255.192 |
> >         > 1e:00:80:00:00:14   | NULL                 | NULL
> >   | NULL
> >         >             |       NULL | 172.30.4.98       | 255.255.255.128
> |
> >         > 1e:00:c9:00:00:5f  |       NULL |              1 |      1 |
> >   NULL |
> >         > NULL |  NULL | NoIqn                               | NULL    |
> > NULL
> >         >     | NULL               |          0 | NULL     | 4.11.0.0 |
> > NULL   |
> >         >  NULL | NULL         | Proxy.2-ConsoleProxyResource
> >         >           |         1 |     0 |           0 | 1492390409 |
> >  146457912294 |
> >         > 2018-06-05 14:09:22 | 2018-06-05 13:46:22 | NULL    |
> > 7 |
> >         > Enabled        | NULL  | NULL        | Disabled     |
> >         >     |  3 | s-1-VM          | 107d0a8e-e2d1-42b5-8b9d-
> ff3845bb556c
> > | Up
> >         >  | SecondaryStorageVM | 172.30.3.34        | 255.255.255.192 |
> >         > 1e:00:3b:00:00:05   | 172.30.3.34        | 255.255.255.192 |
> >         > 1e:00:3b:00:00:05   | NULL                 | NULL
> >   | NULL
> >         >             |       NULL | 172.30.4.86       | 255.255.255.128
> |
> >         > 1e:00:d9:00:00:53  |       NULL |              1 |      1 |
> >   NULL |
> >         > NULL |  NULL | NoIqn                               | NULL    |
> > NULL
> >         >     | NULL               |          0 | NULL     | 4.11.0.0 |
> > NULL   |
> >         >  NULL | NULL         | s-1-VM-NfsSecondaryStorageResource
> >         >             |         1 |     0 |           0 | 1492390407 |
> >  146457912294
> >         > | 2018-06-05 14:09:22 | 2018-06-05 13:46:27 | NULL    |
> >   7 |
> >         > Enabled        | NULL  | NULL        | Disabled     |
> >         >     |  4 | dcp-cscn2.local | f0c076cb-112f-4f4b-a5a4-
> 1a96ffac9794
> > | Up
> >         >  | Routing            | 172.30.3.4         | 255.255.255.192 |
> >         > 00:26:b9:4a:97:7d   | 172.30.3.4         | 255.255.255.192 |
> >         > 00:26:b9:4a:97:7d   | NULL                 | NULL
> >   | NULL
> >         >             |          1 | 172.30.4.4        | 255.255.255.128
> |
> >         > 00:26:b9:4a:97:7e  |       NULL |              1 |      1 |
> >      1 |
> >         >   2 |  2999 | iqn.1994-05.com.redhat:e9b4aa7e7881 | NULL    |
> > KVM
> >         >      | NULL               | 7510159360 | NULL     | 4.11.0.0 |
> > NULL   |
> >         >    NULL | hvm,snapshot | 40e58399-fc7a-3a59-8f48-16d0f99b11c9-
> > LibvirtComputingResource
> >         > |         1 |     0 |           0 | 1492450882 |
>  146457912294 |
> >         > 2018-06-05 14:09:22 | 2018-06-05 13:46:33 | NULL    |
> > 8 |
> >         > Enabled        | NULL  | NULL        | Disabled     |
> >         >     |  5 | dcp-cscn3.local | 0368ae16-550f-43a9-bb40-
> ee29d2b5c274
> > | Up
> >         >  | Routing            | 172.30.3.5         | 255.255.255.192 |
> >         > 00:24:e8:73:6a:b2   | 172.30.3.5         | 255.255.255.192 |
> >         > 00:24:e8:73:6a:b2   | NULL                 | NULL
> >   | NULL
> >         >             |          1 | 172.30.4.5        | 255.255.255.128
> |
> >         > 00:24:e8:73:6a:b3  |       NULL |              1 |      1 |
> >      1 |
> >         >   2 |  3000 | iqn.1994-05.com.redhat:ccdce43aff1c | NULL    |
> > KVM
> >         >      | NULL               | 7510159360 | NULL     | 4.11.0.0 |
> > NULL   |
> >         >    NULL | hvm,snapshot | 10bb1c01-0e92-3108-8209-37f3eebad8fb-
> > LibvirtComputingResource
> >         > |         1 |     0 |           0 | 1492390408 |
>  146457912294 |
> >         > 2018-06-05 14:09:22 | 2018-06-05 13:47:04 | NULL    |
> > 6 |
> >         > Enabled        | NULL  | NULL        | Disabled     |
> >         >     +----+-----------------+------
> ------------------------------
> >         > --+--------+--------------------+--------------------+------
> >         > -----------+---------------------+--------------------+-----
> >         > ------------+---------------------+----------------------+--
> >         > ---------------------+-------------------+------------+-----
> >         > --------------+-----------------+--------------------+------
> >         > ------+----------------+--------+-------------+------+------
> >         > -+-------------------------------------+---------+----------
> >         > -------+--------------------+------------+----------+-------
> >         > ---+--------+------------+--------------+-------------------
> >         > --------------------------------------------+-----------+---
> >         > ----+-------------+------------+----------------+-----------
> >         > ----------+---------------------+---------+--------------+--
> >         > --------------+-------+-------------+--------------+
> >         >     5 rows in set (0.00 sec)
> >         >
> >         >
> >         >
> >         >     and you can see that it says the storage IP address is the
> > same as the
> >         > private IP address (the management network).
> >         >
> >         >
> >         >     I also ran the command you provided using the Cluster ID
> > number from
> >         > the table above -
> >         >
> >         >
> >         >
> >         >     mysql> select * from cloud.storage_pool where cluster_id =
> 1
> > and
> >         > removed is not null;
> >         >     Empty set (0.00 sec)
> >         >
> >         >     mysql>
> >         >
> >         >     So assuming I am reading this correctly that seems to be
> the
> > issue.
> >         >
> >         >
> >         >     I am at a loss as to why though.
> >         >
> >         >
> >         >     I have a separate NIC for storage as described. When I add
> > the zone
> >         > and get to the storage web page I exclude the IPs already used
> > for the
> >         > compute node NICs and the NFS server itself. I do this because
> > initially I
> >         > didn't and the SSVM started using the IP address of the NFS
> > server.
> >         >
> >         >
> >         >     So the range is 172.30.5.1 -> 15 and the range I fill in is
> >         > 172.30.5.10 -> 172.30.5.14.
> >         >
> >         >
> >         >     And I used the label "cloudbr2" for storage.
> >         >
> >         >
> >         >     I must be doing this wrong somehow.
> >         >
> >         >
> >         >     Any pointers would be much appreciated.
> >         >
> >         >
> >         >
> >         >
> >         >     ________________________________
> >         >     From: Rafael Weingärtner <rafaelweingartner@xxxxxxxxx>
> >         >     Sent: 05 June 2018 16:13
> >         >     To: users
> >         >     Subject: Re: advanced networking with public IPs direct to
> > VMs
> >         >
> >         >     That is interesting. Let's see the source of all truth...
> >         >     This is the code that is generating that odd message.
> >         >
> >         >     >     List<StoragePoolVO> clusterPools =
> >         >     > _storagePoolDao.listPoolsByCluster(agent.
> getClusterId());
> >         >     >         boolean hasNfs = false;
> >         >     >         for (StoragePoolVO pool : clusterPools) {
> >         >     >             if (pool.getPoolType() == StoragePoolType.
> > NetworkFilesystem)
> >         > {
> >         >     >                 hasNfs = true;
> >         >     >                 break;
> >         >     >             }
> >         >     >         }
> >         >     >         if (!hasNfs) {
> >         >     >             s_logger.warn(
> >         >     >                     "Agent investigation was requested on
> > host " +
> >         > agent +
> >         >     > ", but host does not support investigation because it has
> > no NFS
> >         > storage.
> >         >     > Skipping investigation.");
> >         >     >             return Status.Disconnected;
> >         >     >         }
> >         >     >
> >         >
> >         >     There are two possibilities here. You do not have any NFS
> > storage? Is
> >         > that
> >         >     the case? Or maybe, for some reason, the call
> >         >     "_storagePoolDao.listPoolsByCluster(agent.getClusterId())"
> > is not
> >         > returning
> >         >     any NFS storage pools. Looking at the "listPoolsByCluster "
> > we will see
> >         >     that the following SQL is used:
> >         >
> >         >     Select * from storage_pool where cluster_id =
> > <host'sClusterId> and
> >         > removed
> >         >     > is not null
> >         >     >
> >         >
> >         >     Can you run that SQL to see the its return when your hosts
> > are marked
> >         > as
> >         >     disconnected?
> >         >
> >         >
> >         > Dag.Sonstebo@xxxxxxxxxxxxx
> >         > www.shapeblue.com<http://www.shapeblue.com>
> Shapeblue - The CloudStack Company<http://www.shapeblue.com/>
> www.shapeblue.com
> ShapeBlue are the largest independent integrator of CloudStack
> technologies globally and are specialists in the design and implementation
> of IaaS cloud infrastructures for both private and public cloud
> implementations.
>
>
>
> >         Shapeblue - The CloudStack Company<http://www.shapeblue.com/>
> >         www.shapeblue.com<http://www.shapeblue.com>
> >         ShapeBlue are the largest independent integrator of CloudStack
> > technologies globally and are specialists in the design and
> implementation
> > of IaaS cloud infrastructures for both private and public cloud
> > implementations.
> >
> >
> >
> >         > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> >         > @shapeblue
> >         >
> >         >
> >         >
> >         > On Tue, Jun 5, 2018 at 11:32 AM, Jon Marshall <
> > jms.123@xxxxxxxxxxxxx>
> >         > wrote:
> >         >
> >         >     > I reran the tests with the 3 NIC setup. When I configured
> > the zone
> >         > through
> >         >     > the UI I used the labels cloudbr0 for management,
> cloudbr1
> > for guest
> >         >     > traffic and cloudbr2 for NFS as per my original response
> > to you.
> >         >     >
> >         >     >
> >         >     > When I pull the power to the node (dcp-cscn2.local) after
> > about 5
> >         > mins
> >         >     > the  host status goes to "Alert" but never to "Down"
> >         >     >
> >         >     >
> >         >     > I get this in the logs -
> >         >     >
> >         >     >
> >         >     > 2018-06-05 15:17:14,382 WARN  [c.c.h.KVMInvestigator]
> >         >     > (AgentTaskPool-1:ctx-f4da4dc9) (logid:138e9a93) Agent
> > investigation
> >         > was
> >         >     > requested on host Host[-4-Routing], but host does not
> > support
> >         > investigation
> >         >     > because it has no NFS storage. Skipping investigation.
> >         >     > 2018-06-05 15:17:14,382 DEBUG [c.c.h.
> > HighAvailabilityManagerImpl]
> >         >     > (AgentTaskPool-1:ctx-f4da4dc9) (logid:138e9a93)
> > KVMInvestigator was
> >         > able to
> >         >     > determine host 4 is in Disconnected
> >         >     > 2018-06-05 15:17:14,382 INFO  [c.c.a.m.AgentManagerImpl]
> >         >     > (AgentTaskPool-1:ctx-f4da4dc9) (logid:138e9a93) The agent
> > from host
> >         > 4 state
> >         >     > determined is Disconnected
> >         >     > 2018-06-05 15:17:14,382 WARN  [c.c.a.m.AgentManagerImpl]
> >         >     > (AgentTaskPool-1:ctx-f4da4dc9) (logid:138e9a93) Agent is
> >         > disconnected but
> >         >     > the host is still up: 4-dcp-cscn2.local
> >         >     >
> >         >     > I don't understand why it thinks there is no NFS storage
> > as each
> >         > compute
> >         >     > node has a dedicated storage NIC.
> >         >     >
> >         >     >
> >         >     > I also don't understand why it thinks the host is still
> up
> > ie. what
> >         > test
> >         >     > is it doing to determine that ?
> >         >     >
> >         >     >
> >         >     > Am I just trying to get something working that is not
> > supported ?
> >         >     >
> >         >     >
> >         >     > ________________________________
> >         >     > From: Rafael Weingärtner <rafaelweingartner@xxxxxxxxx>
> >         >     > Sent: 04 June 2018 15:31
> >         >     > To: users
> >         >     > Subject: Re: advanced networking with public IPs direct
> to
> > VMs
> >         >     >
> >         >     > What type of failover are you talking about?
> >         >     > What ACS version are you using?
> >         >     > What hypervisor are you using?
> >         >     > How are you configuring your NICs in the hypervisor?
> >         >     > How are you configuring the traffic labels in ACS?
> >         >     >
> >         >     > On Mon, Jun 4, 2018 at 11:29 AM, Jon Marshall <
> > jms.123@xxxxxxxxxxxxx
> >         > >
> >         >     > wrote:
> >         >     >
> >         >     > > Hi all
> >         >     > >
> >         >     > >
> >         >     > > I am close to giving up on basic networking as I just
> > cannot get
> >         > failover
> >         >     > > working with multiple NICs (I am not even sure it is
> > supported).
> >         >     > >
> >         >     > >
> >         >     > > What I would like is to use 3 NICs for management,
> > storage and
> >         > guest
> >         >     > > traffic. I would like to assign public IPs direct to
> the
> > VMs which
> >         > is
> >         >     > why I
> >         >     > > originally chose basic.
> >         >     > >
> >         >     > >
> >         >     > > If I switch to advanced networking do I just configure
> a
> > guest VM
> >         > with
> >         >     > > public IPs on one NIC and not both with the public
> > traffic -
> >         >     > >
> >         >     > >
> >         >     > > would this work ?
> >         >     > >
> >         >     >
> >         >     >
> >         >     >
> >         >     > --
> >         >     > Rafael Weingärtner
> >         >     >
> >         >
> >         >
> >         >
> >         >     --
> >         >     Rafael Weingärtner
> >         >
> >         >
> >         >
> >
> >
> >         --
> >         Rafael Weingärtner
> >
> >
> >
> >     Dag.Sonstebo@xxxxxxxxxxxxx
> >     www.shapeblue.com<http://www.shapeblue.com>
> >     53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> >     @shapeblue
> >
> >
> >
> >
> >
> >
> > Dag.Sonstebo@xxxxxxxxxxxxx
> > www.shapeblue.com<http://www.shapeblue.com>
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> >
>
>
> --
> Rafael Weingärtner
>



-- 
Rafael Weingärtner