Re: Iptables on Virtual router

[Marc-Aurèle Brothier]

Hi Varun,

The file is for the firewall are all comig from the system VM image, you
can find them here depending on the type of the system:
https://github.com/apache/cloudstack/tree/master/systemvm/debian/etc/iptables.
After the system vm has booted and the SSH is available, the agent daemon
sends a command through ssh to setup the system VM with its correspondig
type (consoleproxy, dhcpsrv, secstorage...) which configures it differently
for each use case. To overcome this, you're best bet is to build a custom
systemVM on which you add an extra systemd script to set up the rules you
need.

On Wed, Mar 7, 2018 at 10:05 AM, Dag Sonstebo 
wrote:

> Hi Varun,
>
> Not sure if I follow your use case – the VR is built to provide services
> to VMs on the internal isolated network / VPC tier, the public interface is
> there for port forwarding / NATing to services hosted on the VMs.
> Hosting DHCP on the VR for clients on the public interface isn’t a
> supported use case – anything on the public interface is by definition
> considered untrusted.
>
> I may have misunderstood you though?
>
> Regards,
> Dag Sonstebo
> Cloud Architect
> ShapeBlue
>
> On 07/03/2018, 03:21, "Kumar, Varun"  wrote:
>
> Thanks Dag.
>
> I am running into a scenario where a VR is required for dhcp service
> on the public Internet facing vlan and want to restrict connections to
> known trusted sources only.
>
> Has anyone in the community run into such a situation before and found
> a workaround ?
>
> Thanks,
> Varun
>
>
> -Original Message-
> From: Dag Sonstebo [mailto:dag.sonst...@shapeblue.com]
> Sent: Tuesday, March 06, 2018 05:41 PM
> To: users@cloudstack.apache.org
> Subject: Re: Iptables on Virtual router
>
> EXTERNAL EMAIL
>
> Hi Varun,
>
> No there’s no method for this, all firewall rules for the VR are
> contained in the CloudStack database and written on demand when the VR is
> created or firewall changes made.
>
> Regards,
> Dag Sonstebo
> Cloud Architect
> ShapeBlue
>
> On 06/03/2018, 11:56, "Kumar, Varun"  wrote:
>
> Hello,
>
> Is it possible to write custom iptables  on the Virtual router
> that's created by cloudstack  and make it persistent across restarts ?
>
> It looks like /etc/iptables/router_rules.v4  on the VR is the file
> that's being created  but I am looking for the script that creates this
> file.
>
> Any insight is appreciated.
>
> Thanks,
> Varun
>
>
>
>
> dag.sonst...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>
>
>
> dag.sonst...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>

Re: KVM HostHA

[Andrija Panic]

Hi Victor,

zero experience here with 4.11 in general, but what are you expecting to
happen ?

you powered off a host, so nothing for IPMI driver to do - host is down
already, no host HA actions are expected afaik.

I guess you might have have wanted to i.e. unplug NIC (cause network issues
on MGMT network), or... kill agent service and then observe the actions.

Were VMs started on another host, in your test?

Cheers

On 7 March 2018 at 18:01, victor  wrote:

> Hello Guys,
>
> I have installed cloudstack 4.11. I have enabled HA for each hosts I have
> added. I have also added ipmi successfully (using ipmi driver).   The hosts
> are showing like the following.
>
> ===
>
> HA Enabled  Yes
> HA StateAvailable
> HA Provider kvmhaprovider
>
> ==
>
> Also the host is showing the following correctly
>
> Resource state --> Enabled
> State --> UP
> Power state --> On
>
> So I have shutdown one of the hosts to see how the KVM hosts Ha is
> working.  I have waited for half an hour. But nothing has happened. What
> will happen to the VM's in that host, if the host failed to back up. There
> isn't much from logs.
>
> Regards
> Victor
>



-- 

Andrija Panić

RE: KVM HostHA

[Paul Angus]

Hi Victor,

What parameters do you have for:

kvm.ha.activity.check.max.attempts
kvm.ha.activity.check.interval
kvm.ha.activity.check.timeout
kvm.ha.health.check.timeout
kvm.ha.degraded.max.period

the logs should show entries relating to these, BUT it's possible that as 
you performed a clean shutdown, the agent could have sent a shutdown ack to the 
management server, so the management server may no longer be polling.  I'm not 
sure about that scenario.

I recently used:
echo c > /proc/sysrq-trigger

as suggested by Nux, to simulate a host crash.

paul.an...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-Original Message-
From: victor  
Sent: 07 March 2018 17:02
To: users@cloudstack.apache.org
Subject: KVM HostHA

Hello Guys,

I have installed cloudstack 4.11. I have enabled HA for each hosts I have 
added. I have also added ipmi successfully (using ipmi driver). The hosts are 
showing like the following.

===

HA Enabled  Yes
HA StateAvailable
HA Provider kvmhaprovider

==

Also the host is showing the following correctly

Resource state --> Enabled
State --> UP
Power state --> On

So I have shutdown one of the hosts to see how the KVM hosts Ha is working.  I 
have waited for half an hour. But nothing has happened. What will happen to the 
VM's in that host, if the host failed to back up. 
There isn't much from logs.

Regards
Victor

KVM HostHA

[victor]

Hello Guys,

I have installed cloudstack 4.11. I have enabled HA for each hosts I 
have added. I have also added ipmi successfully (using ipmi driver).   
The hosts are showing like the following.


===

HA Enabled  Yes
HA StateAvailable
HA Provider kvmhaprovider

==

Also the host is showing the following correctly

Resource state --> Enabled
State --> UP
Power state --> On

So I have shutdown one of the hosts to see how the KVM hosts Ha is 
working.  I have waited for half an hour. But nothing has happened. What 
will happen to the VM's in that host, if the host failed to back up. 
There isn't much from logs.


Regards
Victor

Re: Change VPC CIDR - and some Mailing List issues

[Andrija Panic]

root@r-5015-VM:~# grep -ir "10.128.0.0/18" /etc/ ### this is VPC CIDR

/etc/iptables/router_rules.v4:-A INPUT -s 10.128.64.0/18 -d 10.128.0.0/18
-j MARK --set-xmark 0x524/0x
/etc/iptables/router_rules.v4:-A FORWARD -s 10.128.64.0/18 -d 10.128.0.0/18
-j MARK --set-xmark 0x524/0x
/etc/iptables/router_rules.v4:-A FORWARD -s 10.128.0.0/18 -d 10.128.64.0/18
-j MARK --set-xmark 0x525/0x
/etc/iptables/router_rules.v4:-A OUTPUT -s 10.128.0.0/18 -d 10.128.64.0/18
-j MARK --set-xmark 0x525/0x
/etc/iptables/router_rules.v4:-A FORWARD -s 10.128.0.0/18 ! -d 10.128.0.0/18
-j ACCEPT
/etc/ipsec.d/ipsec.vpn-185.39.XXX.YYY.conf: leftsubnet=10.128.0.0/18
/etc/cloudstack/cmdline.json:"vpccidr": "10.128.0.0/18"
/etc/cloudstack/site2sitevpn.json:"local_guest_cidr": "10.128.0.0/18
",

So just restart VPC and be safe better than sorry :)

Cheers

On 7 March 2018 at 14:21,  wrote:

> Hi,
>
> As far as I know, when creating a site 2 site VPN, you can only specify
> the remote networks. The local network is always set to the whole VPC CIDR.
> Or am I wrong?
>
> Regards
> Daniel
>
> On 07.03.18, 12:39, "Rafael Weingärtner" 
> wrote:
>
> I agree with you. I was not aware of that link in ACS website. I
> already
> created a task for myself to fix that.
>
> I thought the VPC CIDR was used only as a logical value internally in
> ACS.
> However, as you pointed out, you can create a VPN to the whole VPC.
> Then,
> yes, a restart would be required.
>
>
> On Wed, Mar 7, 2018 at 8:33 AM, 
> wrote:
>
> > Hi,
> >
> > Maybe we could link to the Apache search system at the page listing
> the
> > Cloudstack Mailing-Lists: https://cloudstack.apache.org/
> mailing-lists.html
> >
> > If you click on the list there, you get to
> http://mail-archives.apache.
> > org/mod_mbox/cloudstack-users/. Then there is markmail linked and
> the
> > https://lists.apache.org/list.html?users@cloudstack.apache.org link
> you
> > shared (which btw looks best to me, thanks).
> >
> > The tiers are going to stay as they are currently. I guess the CIDR
> is
> > used in the Strongswan VPN configuration as local network, so I
> guess a
> > restart might be required.
> >
> > Other thoughts?
> >
> > Thanks
> > Daniel
> >
> > On 07.03.18, 12:25, "Rafael Weingärtner" <
> rafaelweingart...@gmail.com>
> > wrote:
> >
> > MarkMail is not an Apache's system. If you want an Apache's
> system to
> > search mailing lists you can use:
> > https://lists.apache.org/list.html?d...@cloudstack.apache.org.
> >
> > Do you intend on changing the Tiers CIDR as well? If it is only
> the
> > VPC,
> > you might not even need to restart with a cleanup. Of course, it
> is
> > always
> > a good practice to test before applying in production.
> >
> > On Wed, Mar 7, 2018 at 8:07 AM,  fraunhofer.de>
> > wrote:
> >
> > > Hi all,
> > >
> > >
> > >
> > > First of all: when trying to search the lists on MarkMail (
> > > https://cloudstack.apache.org/mailing-lists.html) I get a
> warning
> > that
> > > the entered information will be transmitted insecurely (no
> HTTPs).
> > If I
> > > accept that, MarkMail redirects back to HTTPs but does not
> present a
> > valid
> > > certificate (unknown issuer, Firefox 58.0.2
> > >
> > >
> > >
> > > Now, to the question:
> > >
> > >
> > >
> > > We have a VPC with a pretty large CIDR (172.19.0.0/16), which
> > however
> > > only has tiers in the upper half (172.19.128.0/17). We now
> would
> > like to
> > > reduce the VPC CIDR. Is it safe to edit this in the database
> and
> > then do a
> > > VPC restart with cleanup? Anything else to consider?
> > >
> > >
> > >
> > > We use VPN s2s tunnel, so I guess we need to change the remote
> > subnet on
> > > the other VPN endpoints, but other than that?
> > >
> > >
> > >
> > > Is it possible like that, any problems to expect?
> > >
> > >
> > >
> > > Thanks and regards
> > >
> > > Daniel
> >
> >
>
>
> --
> Rafael Weingärtner
>
>


-- 

Andrija Panić

Re: Change VPC CIDR - and some Mailing List issues

[daniel.herrmann]

Hi,

As far as I know, when creating a site 2 site VPN, you can only specify the 
remote networks. The local network is always set to the whole VPC CIDR. Or am I 
wrong?

Regards
Daniel

On 07.03.18, 12:39, "Rafael Weingärtner"  wrote:

I agree with you. I was not aware of that link in ACS website. I already
created a task for myself to fix that.

I thought the VPC CIDR was used only as a logical value internally in ACS.
However, as you pointed out, you can create a VPN to the whole VPC. Then,
yes, a restart would be required.


On Wed, Mar 7, 2018 at 8:33 AM,  wrote:

> Hi,
>
> Maybe we could link to the Apache search system at the page listing the
> Cloudstack Mailing-Lists: https://cloudstack.apache.org/mailing-lists.html
>
> If you click on the list there, you get to http://mail-archives.apache.
> org/mod_mbox/cloudstack-users/. Then there is markmail linked and the
> https://lists.apache.org/list.html?users@cloudstack.apache.org link you
> shared (which btw looks best to me, thanks).
>
> The tiers are going to stay as they are currently. I guess the CIDR is
> used in the Strongswan VPN configuration as local network, so I guess a
> restart might be required.
>
> Other thoughts?
>
> Thanks
> Daniel
>
> On 07.03.18, 12:25, "Rafael Weingärtner" 
> wrote:
>
> MarkMail is not an Apache's system. If you want an Apache's system to
> search mailing lists you can use:
> https://lists.apache.org/list.html?d...@cloudstack.apache.org.
>
> Do you intend on changing the Tiers CIDR as well? If it is only the
> VPC,
> you might not even need to restart with a cleanup. Of course, it is
> always
> a good practice to test before applying in production.
>
> On Wed, Mar 7, 2018 at 8:07 AM, 
> wrote:
>
> > Hi all,
> >
> >
> >
> > First of all: when trying to search the lists on MarkMail (
> > https://cloudstack.apache.org/mailing-lists.html) I get a warning
> that
> > the entered information will be transmitted insecurely (no HTTPs).
> If I
> > accept that, MarkMail redirects back to HTTPs but does not present a
> valid
> > certificate (unknown issuer, Firefox 58.0.2
> >
> >
> >
> > Now, to the question:
> >
> >
> >
> > We have a VPC with a pretty large CIDR (172.19.0.0/16), which
> however
> > only has tiers in the upper half (172.19.128.0/17). We now would
> like to
> > reduce the VPC CIDR. Is it safe to edit this in the database and
> then do a
> > VPC restart with cleanup? Anything else to consider?
> >
> >
> >
> > We use VPN s2s tunnel, so I guess we need to change the remote
> subnet on
> > the other VPN endpoints, but other than that?
> >
> >
> >
> > Is it possible like that, any problems to expect?
> >
> >
> >
> > Thanks and regards
> >
> > Daniel
>
>


-- 
Rafael Weingärtner



smime.p7s
Description: S/MIME cryptographic signature

Re: Change VPC CIDR - and some Mailing List issues

[Rafael Weingärtner]

I agree with you. I was not aware of that link in ACS website. I already
created a task for myself to fix that.

I thought the VPC CIDR was used only as a logical value internally in ACS.
However, as you pointed out, you can create a VPN to the whole VPC. Then,
yes, a restart would be required.


On Wed, Mar 7, 2018 at 8:33 AM,  wrote:

> Hi,
>
> Maybe we could link to the Apache search system at the page listing the
> Cloudstack Mailing-Lists: https://cloudstack.apache.org/mailing-lists.html
>
> If you click on the list there, you get to http://mail-archives.apache.
> org/mod_mbox/cloudstack-users/. Then there is markmail linked and the
> https://lists.apache.org/list.html?users@cloudstack.apache.org link you
> shared (which btw looks best to me, thanks).
>
> The tiers are going to stay as they are currently. I guess the CIDR is
> used in the Strongswan VPN configuration as local network, so I guess a
> restart might be required.
>
> Other thoughts?
>
> Thanks
> Daniel
>
> On 07.03.18, 12:25, "Rafael Weingärtner" 
> wrote:
>
> MarkMail is not an Apache's system. If you want an Apache's system to
> search mailing lists you can use:
> https://lists.apache.org/list.html?d...@cloudstack.apache.org.
>
> Do you intend on changing the Tiers CIDR as well? If it is only the
> VPC,
> you might not even need to restart with a cleanup. Of course, it is
> always
> a good practice to test before applying in production.
>
> On Wed, Mar 7, 2018 at 8:07 AM, 
> wrote:
>
> > Hi all,
> >
> >
> >
> > First of all: when trying to search the lists on MarkMail (
> > https://cloudstack.apache.org/mailing-lists.html) I get a warning
> that
> > the entered information will be transmitted insecurely (no HTTPs).
> If I
> > accept that, MarkMail redirects back to HTTPs but does not present a
> valid
> > certificate (unknown issuer, Firefox 58.0.2
> >
> >
> >
> > Now, to the question:
> >
> >
> >
> > We have a VPC with a pretty large CIDR (172.19.0.0/16), which
> however
> > only has tiers in the upper half (172.19.128.0/17). We now would
> like to
> > reduce the VPC CIDR. Is it safe to edit this in the database and
> then do a
> > VPC restart with cleanup? Anything else to consider?
> >
> >
> >
> > We use VPN s2s tunnel, so I guess we need to change the remote
> subnet on
> > the other VPN endpoints, but other than that?
> >
> >
> >
> > Is it possible like that, any problems to expect?
> >
> >
> >
> > Thanks and regards
> >
> > Daniel
>
>


-- 
Rafael Weingärtner

Re: Change VPC CIDR - and some Mailing List issues

[daniel.herrmann]

Hi,

Maybe we could link to the Apache search system at the page listing the 
Cloudstack Mailing-Lists: https://cloudstack.apache.org/mailing-lists.html

If you click on the list there, you get to 
http://mail-archives.apache.org/mod_mbox/cloudstack-users/. Then there is 
markmail linked and the 
https://lists.apache.org/list.html?users@cloudstack.apache.org link you shared 
(which btw looks best to me, thanks).

The tiers are going to stay as they are currently. I guess the CIDR is used in 
the Strongswan VPN configuration as local network, so I guess a restart might 
be required.

Other thoughts?

Thanks
Daniel

On 07.03.18, 12:25, "Rafael Weingärtner"  wrote:

MarkMail is not an Apache's system. If you want an Apache's system to
search mailing lists you can use:
https://lists.apache.org/list.html?d...@cloudstack.apache.org.

Do you intend on changing the Tiers CIDR as well? If it is only the VPC,
you might not even need to restart with a cleanup. Of course, it is always
a good practice to test before applying in production.

On Wed, Mar 7, 2018 at 8:07 AM,  wrote:

> Hi all,
>
>
>
> First of all: when trying to search the lists on MarkMail (
> https://cloudstack.apache.org/mailing-lists.html) I get a warning that
> the entered information will be transmitted insecurely (no HTTPs). If I
> accept that, MarkMail redirects back to HTTPs but does not present a valid
> certificate (unknown issuer, Firefox 58.0.2
>
>
>
> Now, to the question:
>
>
>
> We have a VPC with a pretty large CIDR (172.19.0.0/16), which however
> only has tiers in the upper half (172.19.128.0/17). We now would like to
> reduce the VPC CIDR. Is it safe to edit this in the database and then do a
> VPC restart with cleanup? Anything else to consider?
>
>
>
> We use VPN s2s tunnel, so I guess we need to change the remote subnet on
> the other VPN endpoints, but other than that?
>
>
>
> Is it possible like that, any problems to expect?
>
>
>
> Thanks and regards
>
> Daniel



smime.p7s
Description: S/MIME cryptographic signature

Re: Change VPC CIDR - and some Mailing List issues

[Rafael Weingärtner]

MarkMail is not an Apache's system. If you want an Apache's system to
search mailing lists you can use:
https://lists.apache.org/list.html?d...@cloudstack.apache.org.

Do you intend on changing the Tiers CIDR as well? If it is only the VPC,
you might not even need to restart with a cleanup. Of course, it is always
a good practice to test before applying in production.

On Wed, Mar 7, 2018 at 8:07 AM,  wrote:

> Hi all,
>
>
>
> First of all: when trying to search the lists on MarkMail (
> https://cloudstack.apache.org/mailing-lists.html) I get a warning that
> the entered information will be transmitted insecurely (no HTTPs). If I
> accept that, MarkMail redirects back to HTTPs but does not present a valid
> certificate (unknown issuer, Firefox 58.0.2
>
>
>
> Now, to the question:
>
>
>
> We have a VPC with a pretty large CIDR (172.19.0.0/16), which however
> only has tiers in the upper half (172.19.128.0/17). We now would like to
> reduce the VPC CIDR. Is it safe to edit this in the database and then do a
> VPC restart with cleanup? Anything else to consider?
>
>
>
> We use VPN s2s tunnel, so I guess we need to change the remote subnet on
> the other VPN endpoints, but other than that?
>
>
>
> Is it possible like that, any problems to expect?
>
>
>
> Thanks and regards
>
> Daniel
>
>
>
> --
>
> Daniel Herrmann
>
> Network Engineer – Fraunhofer Private Cloud
>
> CCIE #55056 (Routing and Switching)
>
> Cisco CCDP, CCIP; Fluke CCTT
>
>
>
> Fraunhoferstraße 5
> ,
> 64283 Darmstadt
>
> Tel.: +49 6151 155346 <+49%206151%20155346>
>
> Mail: daniel.herrm...@zv.fraunhofer.de
>
>
>



-- 
Rafael Weingärtner

Change VPC CIDR - and some Mailing List issues

[daniel.herrmann]

Hi all,

 

First of all: when trying to search the lists on MarkMail 
(https://cloudstack.apache.org/mailing-lists.html) I get a warning that the 
entered information will be transmitted insecurely (no HTTPs). If I accept 
that, MarkMail redirects back to HTTPs but does not present a valid certificate 
(unknown issuer, Firefox 58.0.2

 

Now, to the question:

 

We have a VPC with a pretty large CIDR (172.19.0.0/16), which however only has 
tiers in the upper half (172.19.128.0/17). We now would like to reduce the VPC 
CIDR. Is it safe to edit this in the database and then do a VPC restart with 
cleanup? Anything else to consider?

 

We use VPN s2s tunnel, so I guess we need to change the remote subnet on the 
other VPN endpoints, but other than that?

 

Is it possible like that, any problems to expect?

 

Thanks and regards

Daniel

 

-- 

Daniel Herrmann

Network Engineer – Fraunhofer Private Cloud

CCIE #55056 (Routing and Switching)

Cisco CCDP, CCIP; Fluke CCTT

 

Fraunhoferstraße 5, 64283 Darmstadt

Tel.: +49 6151 155346

Mail: daniel.herrm...@zv.fraunhofer.de

 



smime.p7s
Description: S/MIME cryptographic signature

Re: VHD import

[Dag Sonstebo]

Thanks for the update Gregoire,

Would you be able to check the vhd-util versions in your working vs not-working 
scenarios?

Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue

On 06/03/2018, 22:11, "Grégoire Lamodière"  wrote:

Hi Dag, All, 

I spent some time working on this matter, and here are the results of my 
tests.
It might be usefull in case anyone has to restore instances from nfs store.

I think I were facing 2 issues.

1/ You are right, in case vm crashed (ie was running at the time of network 
crash), you may assume around 50% luck to restore it easily.
2/ vhd-util version used in the xenserver seems to be the key of the 
process.

I made the following tries :

- take vhd from cs 4.9.3 / xenserver 7.0
- download VHD-UTIL from install guide url
- Import it to cs 4.11 / xenserver 7.0 => not working
- Upgrade the xenserver to 7.2 => import still not working
- Import directly to xenserver 7.0 / 7.2 => working 100%

- make exactly the same, copying vhd-util from original cs 4.9.3 management 
server to the new one
- Import it to cs 4.11 / xenserver 7.0 => working
- Upgrade the xenserver to 7.2 => import working

So from what I can see :
Vdi-import always works in a Xenserver perspective, but in some cases vm 
won't start properly if they were inconsistent.

When vhd is downloaded as a template in cs, the errors reported were mostly 
post-download errors, ex. In the ssvm script :
vhd-util set -n ${tmpltimg2} -f "hidden" -v "0" > /dev/null
rollback_if_needed $tmpltfs $? "vhd remove $tmpltimg2 hidden failed\n

That’s all for my feedback.
In case anyone needs info or scripts, I'll be happy to share.

Now it's time to continue my work moving to KVM, but that is another story.

Regards

Grégoire

---
Grégoire Lamodière
T/ + 33 6 76 27 03 31
F/ + 33 1 75 43 89 71

-Message d'origine-
De : Grégoire Lamodière [mailto:g.lamodi...@dimsi.fr] 
Envoyé : vendredi 23 février 2018 21:10
À : users@cloudstack.apache.org
Objet : RE: VHD import

Hi Dag, 

I am still trying to understand, but some instances crashed where some 
others shutdown properly.
So far, I can confirm that all vhd (after coalesce) can be imported to Xen, 
and most of them fail to import as VHD.
Some failure imports are successful after the Xen import step, but some 
still fail after the xe vhd-export (xen vm is working fine)

The strange thing is all vhd sound good (all steps of the cs script pass, 
but the process results in cs errors).
This is not a big deal, as we are moving to KVM, but I hope we won't have 
the same issues with kvm nfs based volumes.
I'll work on this a bit this weekend, so I can make a proper feedback.

Anyway, once again, thanks for your blog post, clear and usefull, as usual.

Grégoire

---
Grégoire Lamodière
T/ + 33 6 76 27 03 31
F/ + 33 1 75 43 89 71


-Message d'origine-
De : Dag Sonstebo [mailto:dag.sonst...@shapeblue.com] 
Envoyé : vendredi 23 février 2018 20:48
À : users@cloudstack.apache.org
Objet : Re: VHD import

Hi Gregoire,

One thing just struck me – what was the status of the VMs you were 
exporting from NFS? Were they cleanly shut down or did they simply crash when 
the hardware failed? If so could you have an issue where the disk you are 
initially exporting isn’t consistent, hence import fails? 

Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue

On 22/02/2018, 09:56, "Dag Sonstebo"  wrote:

Hi Gregoire,

Glad the blog post is of use. It’s a while since I wrote it so I had to 
re-read it myself.  I have not come across this problem – but as you can 
probably guess we luckily don’t have to do this recovery procedure very often.

I can only assume same as yourself that the vhd-util coalesce using the 
downloaded vhd-util binary must give a slightly different format header which 
the import in CloudStack doesn’t like but XS is quite happy about. Also keep in 
mind that the vhd-util from 
http://download.cloud.com.s3.amazonaws.com/tools/vhd-util is slightly different 
than the one you find on the XenServers, so this may also be a factor.

Please let us know how you get on with your investigation – if you find 
the root cause let me know and I’ll add it as a subnote to the original article 
(don’t worry you’ll get the credit ( ).

Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue

On 22/02/2018, 00:10, "Grégoire Lamodière"  wrote:

Dear All,

I recently lost a Xen 7 pool managed by CS 4.11 (hardware issue).

Re: Iptables on Virtual router

[Dag Sonstebo]

Hi Varun,

Not sure if I follow your use case – the VR is built to provide services to VMs 
on the internal isolated network / VPC tier, the public interface is there for 
port forwarding / NATing to services hosted on the VMs.
Hosting DHCP on the VR for clients on the public interface isn’t a supported 
use case – anything on the public interface is by definition considered 
untrusted.

I may have misunderstood you though?

Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue

On 07/03/2018, 03:21, "Kumar, Varun"  wrote:

Thanks Dag. 

I am running into a scenario where a VR is required for dhcp service on the 
public Internet facing vlan and want to restrict connections to known trusted 
sources only.

Has anyone in the community run into such a situation before and found a 
workaround ? 

Thanks,
Varun


-Original Message-
From: Dag Sonstebo [mailto:dag.sonst...@shapeblue.com] 
Sent: Tuesday, March 06, 2018 05:41 PM
To: users@cloudstack.apache.org
Subject: Re: Iptables on Virtual router

EXTERNAL EMAIL

Hi Varun,

No there’s no method for this, all firewall rules for the VR are contained 
in the CloudStack database and written on demand when the VR is created or 
firewall changes made. 

Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue

On 06/03/2018, 11:56, "Kumar, Varun"  wrote:

Hello,

Is it possible to write custom iptables  on the Virtual router that's 
created by cloudstack  and make it persistent across restarts ?

It looks like /etc/iptables/router_rules.v4  on the VR is the file 
that's being created  but I am looking for the script that creates this file.

Any insight is appreciated.

Thanks,
Varun




dag.sonst...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 




dag.sonst...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

RE: CS fail after upgrade to 4.11

[Piotr Pisz]

Hi Paul,

Done roll back, run sql script and run managemen server (db upgrade in startup 
performer correctly).

Regards,
Piotr


-Original Message-
From: Paul Angus [mailto:paul.an...@shapeblue.com] 
Sent: Wednesday, March 7, 2018 9:16 AM
To: pp...@pulab.pl; users@cloudstack.apache.org
Subject: RE: CS fail after upgrade to 4.11

Hi Piotr,

Did you roll back and start the upgrade again, or just run the sql statements?  

paul.an...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
  
 


-Original Message-
From: Piotr Pisz 
Sent: 07 March 2018 07:42
To: Paul Angus ; users@cloudstack.apache.org
Subject: RE: CS fail after upgrade to 4.11

Hi Paul,

You were right and the script helped, the upgrade was a success.
Unfortunately, we have a strange symptom, in UI all hosts are not visible (see 
picture). There are no major errors in the log.
On DB all hosts have status Up but all operation like VM power on ending with 
info "No host are available".

What could be the reason?

Regards,
Piotr

2018-03-07 08:53:07,405 DEBUG [c.c.s.StatsCollector] 
(StatsCollector-6:ctx-383073e7) (logid:a0a38b47) HostStatsCollector is 
running...
2018-03-07 08:53:07,451 DEBUG [c.c.a.t.Request] (StatsCollector-6:ctx-383073e7) 
(logid:a0a38b47) Seq 3-8238491093344190514: Received:  { Ans: , MgmtId: 
119496918425704, via: 3(dc13-r4-wpr1-h1.nubilum.opegieka.pl), Ver: v1, Flags: 
10, { GetHostStatsAnswer } }
2018-03-07 08:53:07,497 DEBUG [c.c.a.t.Request] (StatsCollector-6:ctx-383073e7) 
(logid:a0a38b47) Seq 5-6845752908579864613: Received:  { Ans: , MgmtId: 
119496918425704, via: 5(dc13-r1-wpr1-h2.nubilum.opegieka.pl), Ver: v1, Flags: 
10, { GetHostStatsAnswer } }
2018-03-07 08:53:07,541 DEBUG [c.c.a.t.Request] (StatsCollector-6:ctx-383073e7) 
(logid:a0a38b47) Seq 25-3432587340986449985: Received:  { Ans: , MgmtId: 
119496918425704, via: 25(dc13-r19-wpr2-n3.nubilum.opegieka.pl), Ver: v1, Flags: 
10, { GetHostStatsAnswer } }
2018-03-07 08:53:07,585 DEBUG [c.c.a.t.Request] (StatsCollector-6:ctx-383073e7) 
(logid:a0a38b47) Seq 29-4613937818241073220: Received:  { Ans: , MgmtId: 
119496918425704, via: 29(dc13-r17-wpr2-n2.nubilum.opegieka.pl), Ver: v1, Flags: 
10, { GetHostStatsAnswer } }
2018-03-07 08:53:07,630 DEBUG [c.c.a.t.Request] (StatsCollector-6:ctx-383073e7) 
(logid:a0a38b47) Seq 37-8468737624293507140: Received:  { Ans: , MgmtId: 
119496918425704, via: 37(dc13-r16-wpr2-n1.nubilum.opegieka.pl), Ver: v1, Flags: 
10, { GetHostStatsAnswer } }
2018-03-07 08:53:07,673 DEBUG [c.c.a.t.Request] (StatsCollector-6:ctx-383073e7) 
(logid:a0a38b47) Seq 48-1969480412044460068: Received:  { Ans: , MgmtId: 
119496918425704, via: 48(dc13-r7-wpr2-v12-n1.nubilum.opegieka.pl), Ver: v1, 
Flags: 10, { GetHostStatsAnswer } }
2018-03-07 08:53:07,718 DEBUG [c.c.a.t.Request] (StatsCollector-6:ctx-383073e7) 
(logid:a0a38b47) Seq 52-3613294276034691098: Received:  { Ans: , MgmtId: 
119496918425704, via: 52(dc13-r9-wpr2-v12-n2.nubilum.opegieka.pl), Ver: v1, 
Flags: 10, { GetHostStatsAnswer } }
2018-03-07 08:53:07,761 DEBUG [c.c.a.t.Request] (StatsCollector-6:ctx-383073e7) 
(logid:a0a38b47) Seq 64-4504162577323917343: Received:  { Ans: , MgmtId: 
119496918425704, via: 64(dc13-r11-wpr2-v12-n4.nubilum.opegieka.pl), Ver: v1, 
Flags: 10, { GetHostStatsAnswer } }
2018-03-07 08:53:07,879 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
(AsyncJobMgr-Heartbeat-1:ctx-75d73769) (logid:4333f9a0) Begin cleanup expired 
async-jobs
2018-03-07 08:53:07,881 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
(AsyncJobMgr-Heartbeat-1:ctx-75d73769) (logid:4333f9a0) End cleanup expired 
async-jobs
2018-03-07 08:53:09,743 DEBUG [c.c.a.t.Request] (StatsCollector-2:ctx-e2109ed5) 
(logid:a7e15ece) Seq 3-8238491093344190515: Received:  { Ans: , MgmtId: 
119496918425704, via: 3(dc13-r4-wpr1-h1.nubilum.opegieka.pl), Ver: v1, Flags: 
10, { GetVmStatsAnswer } }
2018-03-07 08:53:09,841 DEBUG [c.c.a.t.Request] (StatsCollector-2:ctx-e2109ed5) 
(logid:a7e15ece) Seq 25-3432587340986449986: Received:  { Ans: , MgmtId: 
119496918425704, via: 25(dc13-r19-wpr2-n3.nubilum.opegieka.pl), Ver: v1, Flags: 
10, { GetVmStatsAnswer } }
2018-03-07 08:53:09,909 DEBUG [c.c.a.t.Request] (StatsCollector-2:ctx-e2109ed5) 
(logid:a7e15ece) Seq 29-4613937818241073221: Received:  { Ans: , MgmtId: 
119496918425704, via: 29(dc13-r17-wpr2-n2.nubilum.opegieka.pl), Ver: v1, Flags: 
10, { GetVmStatsAnswer } }
2018-03-07 08:53:09,991 DEBUG [c.c.a.t.Request] (StatsCollector-2:ctx-e2109ed5) 
(logid:a7e15ece) Seq 37-8468737624293507141: Received:  { Ans: , MgmtId: 
119496918425704, via: 37(dc13-r16-wpr2-n1.nubilum.opegieka.pl), Ver: v1, Flags: 
10, { GetVmStatsAnswer } }
2018-03-07 08:53:10,042 DEBUG [c.c.a.t.Request] (StatsCollector-2:ctx-e2109ed5) 
(logid:a7e15ece) Seq 48-1969480412044460069: Received:  { Ans: , MgmtId: 
119496918425704, via: 48(dc13-r7-wpr2-v12-n1.nubilum.opegieka.pl), Ver: v1, 
Flags: 10, { GetVmStatsAnswer } }
2018-03-07 

RE: CS fail after upgrade to 4.11

[Paul Angus]

Hi Piotr,

Did you roll back and start the upgrade again, or just run the sql statements?  

paul.an...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-Original Message-
From: Piotr Pisz  
Sent: 07 March 2018 07:42
To: Paul Angus ; users@cloudstack.apache.org
Subject: RE: CS fail after upgrade to 4.11

Hi Paul,

You were right and the script helped, the upgrade was a success.
Unfortunately, we have a strange symptom, in UI all hosts are not visible (see 
picture). There are no major errors in the log.
On DB all hosts have status Up but all operation like VM power on ending with 
info "No host are available".

What could be the reason?

Regards,
Piotr

2018-03-07 08:53:07,405 DEBUG [c.c.s.StatsCollector] 
(StatsCollector-6:ctx-383073e7) (logid:a0a38b47) HostStatsCollector is 
running...
2018-03-07 08:53:07,451 DEBUG [c.c.a.t.Request] (StatsCollector-6:ctx-383073e7) 
(logid:a0a38b47) Seq 3-8238491093344190514: Received:  { Ans: , MgmtId: 
119496918425704, via: 3(dc13-r4-wpr1-h1.nubilum.opegieka.pl), Ver: v1, Flags: 
10, { GetHostStatsAnswer } }
2018-03-07 08:53:07,497 DEBUG [c.c.a.t.Request] (StatsCollector-6:ctx-383073e7) 
(logid:a0a38b47) Seq 5-6845752908579864613: Received:  { Ans: , MgmtId: 
119496918425704, via: 5(dc13-r1-wpr1-h2.nubilum.opegieka.pl), Ver: v1, Flags: 
10, { GetHostStatsAnswer } }
2018-03-07 08:53:07,541 DEBUG [c.c.a.t.Request] (StatsCollector-6:ctx-383073e7) 
(logid:a0a38b47) Seq 25-3432587340986449985: Received:  { Ans: , MgmtId: 
119496918425704, via: 25(dc13-r19-wpr2-n3.nubilum.opegieka.pl), Ver: v1, Flags: 
10, { GetHostStatsAnswer } }
2018-03-07 08:53:07,585 DEBUG [c.c.a.t.Request] (StatsCollector-6:ctx-383073e7) 
(logid:a0a38b47) Seq 29-4613937818241073220: Received:  { Ans: , MgmtId: 
119496918425704, via: 29(dc13-r17-wpr2-n2.nubilum.opegieka.pl), Ver: v1, Flags: 
10, { GetHostStatsAnswer } }
2018-03-07 08:53:07,630 DEBUG [c.c.a.t.Request] (StatsCollector-6:ctx-383073e7) 
(logid:a0a38b47) Seq 37-8468737624293507140: Received:  { Ans: , MgmtId: 
119496918425704, via: 37(dc13-r16-wpr2-n1.nubilum.opegieka.pl), Ver: v1, Flags: 
10, { GetHostStatsAnswer } }
2018-03-07 08:53:07,673 DEBUG [c.c.a.t.Request] (StatsCollector-6:ctx-383073e7) 
(logid:a0a38b47) Seq 48-1969480412044460068: Received:  { Ans: , MgmtId: 
119496918425704, via: 48(dc13-r7-wpr2-v12-n1.nubilum.opegieka.pl), Ver: v1, 
Flags: 10, { GetHostStatsAnswer } }
2018-03-07 08:53:07,718 DEBUG [c.c.a.t.Request] (StatsCollector-6:ctx-383073e7) 
(logid:a0a38b47) Seq 52-3613294276034691098: Received:  { Ans: , MgmtId: 
119496918425704, via: 52(dc13-r9-wpr2-v12-n2.nubilum.opegieka.pl), Ver: v1, 
Flags: 10, { GetHostStatsAnswer } }
2018-03-07 08:53:07,761 DEBUG [c.c.a.t.Request] (StatsCollector-6:ctx-383073e7) 
(logid:a0a38b47) Seq 64-4504162577323917343: Received:  { Ans: , MgmtId: 
119496918425704, via: 64(dc13-r11-wpr2-v12-n4.nubilum.opegieka.pl), Ver: v1, 
Flags: 10, { GetHostStatsAnswer } }
2018-03-07 08:53:07,879 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
(AsyncJobMgr-Heartbeat-1:ctx-75d73769) (logid:4333f9a0) Begin cleanup expired 
async-jobs
2018-03-07 08:53:07,881 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
(AsyncJobMgr-Heartbeat-1:ctx-75d73769) (logid:4333f9a0) End cleanup expired 
async-jobs
2018-03-07 08:53:09,743 DEBUG [c.c.a.t.Request] (StatsCollector-2:ctx-e2109ed5) 
(logid:a7e15ece) Seq 3-8238491093344190515: Received:  { Ans: , MgmtId: 
119496918425704, via: 3(dc13-r4-wpr1-h1.nubilum.opegieka.pl), Ver: v1, Flags: 
10, { GetVmStatsAnswer } }
2018-03-07 08:53:09,841 DEBUG [c.c.a.t.Request] (StatsCollector-2:ctx-e2109ed5) 
(logid:a7e15ece) Seq 25-3432587340986449986: Received:  { Ans: , MgmtId: 
119496918425704, via: 25(dc13-r19-wpr2-n3.nubilum.opegieka.pl), Ver: v1, Flags: 
10, { GetVmStatsAnswer } }
2018-03-07 08:53:09,909 DEBUG [c.c.a.t.Request] (StatsCollector-2:ctx-e2109ed5) 
(logid:a7e15ece) Seq 29-4613937818241073221: Received:  { Ans: , MgmtId: 
119496918425704, via: 29(dc13-r17-wpr2-n2.nubilum.opegieka.pl), Ver: v1, Flags: 
10, { GetVmStatsAnswer } }
2018-03-07 08:53:09,991 DEBUG [c.c.a.t.Request] (StatsCollector-2:ctx-e2109ed5) 
(logid:a7e15ece) Seq 37-8468737624293507141: Received:  { Ans: , MgmtId: 
119496918425704, via: 37(dc13-r16-wpr2-n1.nubilum.opegieka.pl), Ver: v1, Flags: 
10, { GetVmStatsAnswer } }
2018-03-07 08:53:10,042 DEBUG [c.c.a.t.Request] (StatsCollector-2:ctx-e2109ed5) 
(logid:a7e15ece) Seq 48-1969480412044460069: Received:  { Ans: , MgmtId: 
119496918425704, via: 48(dc13-r7-wpr2-v12-n1.nubilum.opegieka.pl), Ver: v1, 
Flags: 10, { GetVmStatsAnswer } }
2018-03-07 08:53:10,110 DEBUG [c.c.a.t.Request] (StatsCollector-2:ctx-e2109ed5) 
(logid:a7e15ece) Seq 64-4504162577323917344: Received:  { Ans: , MgmtId: 
119496918425704, via: 64(dc13-r11-wpr2-v12-n4.nubilum.opegieka.pl), Ver: v1, 
Flags: 10, { GetVmStatsAnswer } }
2018-03-07 08:53:15,190 DEBUG [c.c.a.m.AgentManagerImpl]