PV vs HVM guest on XenServer 7.0

2018-04-11 Thread Yiping Zhang 
Hi, list:


I am in the process of upgrading my hypervisors clusters from XenServer 6.5 to 
7.0 for all my ACS instances.

My XS 7.0 clusters are patched up to XS70E050.

During cluster rolling upgrade, VM instances are live migrated several times, 
eventually all of them running on XS 7.0 hosts.
However, out of a hundred or so instances, a few of rhle 6.x VM got stuck at 
“Plex86/Bochs VGABios …” screen with at least one vCPU at 100%.
Comparing VM parameters between running and stuck instances, I can see that 
running instances are PV guests while stuck instances are HVM guests.
RHEL 7.x guest are always in HVM mode and always runs on both XS 6.5 and 7.0 
hosts.

Running RHEL6.x guests:

   HVM-boot-policy ( RW):

   HVM-boot-params (MRW):

 HVM-shadow-multiplier ( RW): 1.000

   PV-args ( RW): graphical utf8

 PV-bootloader ( RW): pygrub

Stuck RHEL 6.x guests:

   HVM-boot-policy ( RW): BIOS order

   HVM-boot-params (MRW): order: dc

 HVM-shadow-multiplier ( RW): 1.000

   PV-args ( RW):

 PV-bootloader ( RW):

Why does CloudStack convert just a few rhel 6.x instances into HVM mode, while 
leaving most in PV mode?
How would I force them back to PV guests?

Thanks for all the help

Yiping

RE: ssvm NFS public ip

2018-04-11 Thread Nicolas Bouige 
Hi ilya,


Thanks for your answer

Yes i did it already with no effect :/


Best regards,

N.B


De : ilya musayev 
Envoyé : mercredi 11 avril 2018 20:26:34
À : users@cloudstack.apache.org
Objet : Re: ssvm NFS public ip

There is a global setting you have to set to use internal non public IP.

Try setting sec.storage.allow.internal.site to an internal network cidr.

You may need to destroy ssvm for settings to take effect. In my case there
is some sort of minor bug where it takes upward of 5 minutes for ssvm to
program the internal routes, but since this is onetime operation - I just
live with it.

On Wed, Apr 11, 2018 at 10:50 AM Nicolas Bouige  wrote:

> a small update about my problem.
>
> I 've recreated the zone from scratch this morning and  one of my
> "cloudbr" used for the secondary storage was misconfigured.
>
> So Now, I can ping the secondary storage from KVM host, CS-MGMT,  SSVM and
> mount the nfs on them...but...the agent still not going up and the
> ssvm_check.sh give me an ip public for the nfs instead of the private.
>
>
> i got only this error in /var/log:cloud.log :
>
> 17:30:22,600 ERROR AgentShell:477 - Unable to start agent: Resource class
> not found: com.cloud.storage.resource.PremiumSecondaryStorageResource due
> to: java.lang.ClassNotFoundException:
> com.cloud.storage.resource.PremiumSecondaryStorageReso
>   urce
> Unable to start agent: Resource class not found:
> com.cloud.storage.resource.Prem
> iumSecondaryStorageResource due to: java.lang.ClassNotFoundException:
> com.cloud.
> storage.resource.PremiumSecondaryStorageResource
>
> i've tried to update a differente systemvm template with no success...
> I 've compared the configuration of the ssvm with one of our deployment
> and i juste noticed the "resource"
> (org.apache.cloudstack.storage.resource.NfsSecondaryResource) was not the
> same.
> i changed it but still the same error...
>
> There is a way to find java binaries/script and  upload them on the ssvm ?
>
> If one of you have an idea, it would be appreciate.
>
> Thanks !
>
> Best regards,
> N.B
>
>

Re: ssvm NFS public ip

2018-04-11 Thread ilya musayev 
There is a global setting you have to set to use internal non public IP.

Try setting sec.storage.allow.internal.site to an internal network cidr.

You may need to destroy ssvm for settings to take effect. In my case there
is some sort of minor bug where it takes upward of 5 minutes for ssvm to
program the internal routes, but since this is onetime operation - I just
live with it.

On Wed, Apr 11, 2018 at 10:50 AM Nicolas Bouige  wrote:

> a small update about my problem.
>
> I 've recreated the zone from scratch this morning and  one of my
> "cloudbr" used for the secondary storage was misconfigured.
>
> So Now, I can ping the secondary storage from KVM host, CS-MGMT,  SSVM and
> mount the nfs on them...but...the agent still not going up and the
> ssvm_check.sh give me an ip public for the nfs instead of the private.
>
>
> i got only this error in /var/log:cloud.log :
>
> 17:30:22,600 ERROR AgentShell:477 - Unable to start agent: Resource class
> not found: com.cloud.storage.resource.PremiumSecondaryStorageResource due
> to: java.lang.ClassNotFoundException:
> com.cloud.storage.resource.PremiumSecondaryStorageReso
>   urce
> Unable to start agent: Resource class not found:
> com.cloud.storage.resource.Prem
> iumSecondaryStorageResource due to: java.lang.ClassNotFoundException:
> com.cloud.
> storage.resource.PremiumSecondaryStorageResource
>
> i've tried to update a differente systemvm template with no success...
> I 've compared the configuration of the ssvm with one of our deployment
> and i juste noticed the "resource"
> (org.apache.cloudstack.storage.resource.NfsSecondaryResource) was not the
> same.
> i changed it but still the same error...
>
> There is a way to find java binaries/script and  upload them on the ssvm ?
>
> If one of you have an idea, it would be appreciate.
>
> Thanks !
>
> Best regards,
> N.B
>
>

RE: ssvm NFS public ip

2018-04-11 Thread Nicolas Bouige 
a small update about my problem.

I 've recreated the zone from scratch this morning and  one of my "cloudbr" 
used for the secondary storage was misconfigured.

So Now, I can ping the secondary storage from KVM host, CS-MGMT,  SSVM and 
mount the nfs on them...but...the agent still not going up and the 
ssvm_check.sh give me an ip public for the nfs instead of the private.


i got only this error in /var/log:cloud.log :

17:30:22,600 ERROR AgentShell:477 - Unable to start agent: Resource class not 
found: com.cloud.storage.resource.PremiumSecondaryStorageResource due to: 
java.lang.ClassNotFoundException: 
com.cloud.storage.resource.PremiumSecondaryStorageReso  
  urce
Unable to start agent: Resource class not found: 
com.cloud.storage.resource.Prem
iumSecondaryStorageResource due to: java.lang.ClassNotFoundException: 
com.cloud.
storage.resource.PremiumSecondaryStorageResource

i've tried to update a differente systemvm template with no success...
I 've compared the configuration of the ssvm with one of our deployment and i 
juste noticed the "resource" 
(org.apache.cloudstack.storage.resource.NfsSecondaryResource) was not the same.
i changed it but still the same error...

There is a way to find java binaries/script and  upload them on the ssvm ?

If one of you have an idea, it would be appreciate.

Thanks !

Best regards,
N.B

Can someone reproduce issue on adding NIC to VM on network created through web-UI after upgrade to 4.11?

2018-04-11 Thread Melanie Desaive 
Hi all,

on one of our two CloudStack instances we have an issue adding NICs to
VMs after upgrading to 4.11.0.0. On another instance the problem does
not occur after upgrade.

Before posting an issue on GitHub I would like to know if someone else
can reproduce the following problem:

Our setup: Advanced Networking, Cloudstack 4.11.0.0 on Ubuntu 14.04 LTS,
MySQL 5.5.59-0ubuntu0.14.04.1

Steps to reproduce issue:

  x Create a new isolated network
  x Wait until network is "implemented"
  x Add NIC on this new network to a VM

=> Textbox: Insufficient capacity when adding NIC to VM[User|i--VM]:
com.cloud.exception.InsufficientAddressCapacityException: Insufficient
address capacityScope=interface com.cloud.dc.DataCenter; id=1
=> No new NIC is added to the VM

For a network created with a CloudMonkey command like the following NICs
can be added to VMs:

create network displaytext=deleteme-cloudmonkey
name=deleteme-cloudmonkey networkofferingid= zoneid=
projectid= gateway=172.17.1.1 netmask=255.255.252.0
networkdomain=deleteme-cloudmonkey.heinlein-intern.d

Greetings,

Melanie

-- 
--

Heinlein Support GmbH
Linux: Akademie - Support - Hosting

http://www.heinlein-support.de
Tel: 030 / 40 50 51 - 0
Fax: 030 / 40 50 51 - 19

Zwangsangaben lt. §35a GmbHG:
HRB 93818 B / Amtsgericht Berlin-Charlottenburg,
Geschäftsführer: Peer Heinlein  -- Sitz: Berlin



signature.asc
Description: OpenPGP digital signature

Re: Egress rules not applied in 4.11.0

2018-04-11 Thread Martin Emrich 

Hi!


Am 11.04.18 um 13:38 schrieb Stephan Seitz:

Hi martin,

I've just read your issue on github and was wondering how you;ve been able to 
select Debian 9.
But maybe you did a fresh installation.

No, Upgrade from 4.9.2.0. I set the OS type to Debian 8 in ACS.
"Debian 9.3" is what XenCenter reports, they probably extract the actual 
OS version from the VM.

Maybe your issue is hot-fixed by registering a template with Debian 7 profile.
I'll try that as my next step (changing the OS type in the database and 
recreating a sytem VM).


Ciao

Martin

Re: Egress rules not applied in 4.11.0

2018-04-11 Thread Stephan Seitz 
Rafael,

don't get confused, I'm not the OP, just added a few thoughts. We are running a 
very similar Infrastructure than the OP, but our systemvm-template is Debian 7 
instead of Debian 9 (he has).
The recent host you questioned is "other linux2.x 64bit" so *should* be (as 
verified :) ) run in HVM.

- Stephan

Am Mittwoch, den 11.04.2018, 09:09 -0300 schrieb Rafael Weingärtner:
> That is interesting. The VM is indeed in HVM mode.
> 
> On Wed, Apr 11, 2018 at 9:04 AM, Stephan Seitz 
> wrote:
> 
> > 
> > # xe vm-param-list uuid=c1bcef11-ffc2-24bd-7c5e-0840fb4f8f49 | grep -e
> > PV-legacy-args -e PV-boot -e HVM-boot -e HVM-shadow
> >    HVM-boot-policy ( RW): BIOS order
> >    HVM-boot-params (MRW): order: dc
> >  HVM-shadow-multiplier ( RW): 1.000
> > PV-legacy-args ( RW):
> >  PV-bootloader ( RW):
> > PV-bootloader-args ( RW):
> > 
> > Am Mittwoch, den 11.04.2018, 09:00 -0300 schrieb Rafael Weingärtner:
> > > 
> > > Xen you execute the following command in your XenServer?
> > > 
> > > > 
> > > > 
> > > > xe vm-param-list uuid=
> > > > 
> > > Then, what is the content of these parameters?
> > > 
> > >    - PV-legacy-args
> > >    - PV-bootloader
> > >    - PV-bootloader-args
> > >    - HVM-boot-policy
> > >    - HVM-boot-params
> > >    - HVM-shadow-multiplier
> > > 
> > > 
> > > It is just to make sure that the VM was indeed created using HVM mode.
> > > 
> > > On Wed, Apr 11, 2018 at 8:55 AM, Stephan Seitz <
> > s.se...@heinlein-support.de>
> > > 
> > > wrote:
> > > 
> > > > 
> > > > 
> > > > Just tried a Debian 9 running on XenServer 6.5 SP1 with model "Other
> > 2.6x
> > > 
> > > > 
> > > > Linux (64-bit)":
> > > > 
> > > > # virt-what --version
> > > > 1.15
> > > > # virt-what
> > > > hyperv
> > > > xen
> > > > xen-domU
> > > > #
> > > > 
> > > > 
> > > > Am Mittwoch, den 11.04.2018, 13:50 +0200 schrieb Stephan Seitz:
> > > > > 
> > > > > 
> > > > > AFAIK not for 6.5 SP1.
> > > > > https://xen-orchestra.com/blog/meltdown-and-spectre-for-xenserver/
> > shows
> > > 
> > > > 
> > > > that 7.x is fixed and gives the hint,
> > > > > 
> > > > > 
> > > > > that HVM guests are not affected (at least for spectre)
> > > > > 
> > > > > https://support.citrix.com/article/CTX231390
> > > > > " 6.2 SP1, and 6.5 SP1 versions of XenServer require extensive
> > > > architectural changes to do so. Citrix is therefore not making
> > hotfixes for
> > > 
> > > > 
> > > > these versions available to customers, and will continue to
> > > > > 
> > > > > 
> > > > > work with hardware vendors on other mitigation strategies. Customers
> > on
> > > 
> > > > 
> > > > the 6.2 SP1 and 6.5 SP1 versions are strongly recommended to upgrade
> > to a
> > > 
> > > > 
> > > > more recent version. "
> > > > > 
> > > > > 
> > > > > 
> > > > > I haven't tried it so far, but recent debian versions were kind of
> > picky
> > > 
> > > > 
> > > > with different kinds of Xen virtualization as I've seen on "regular"
> > VMs.
> > > 
> > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > Am Mittwoch, den 11.04.2018, 11:42 + schrieb Paul Angus:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > virt-what will give 'xen-domU' for paravirtualized guests. Didn't
> > > > XenServer make some kind of change around this as a Meltdown/Spectre
> > > > migation?
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Kind regards,
> > > > > > 
> > > > > > Paul Angus
> > > > > > 
> > > > > > paul.an...@shapeblue.com
> > > > > > www.shapeblue.com
> > > > > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > > > > > @shapeblue
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > -Original Message-
> > > > > > From: Stephan Seitz 
> > > > > > Sent: 11 April 2018 12:38
> > > > > > To: users@cloudstack.apache.org
> > > > > > Subject: Re: Egress rules not applied in 4.11.0
> > > > > > 
> > > > > > Hi martin,
> > > > > > 
> > > > > > I've just read your issue on github and was wondering how you;ve
> > been
> > > 
> > > > 
> > > > able to select Debian 9.
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > But maybe you did a fresh installation.
> > > > > > 
> > > > > > We did an update from 4.9.2 to 4.11.0 and were able to select
> > "Debian
> > > 
> > > > 
> > > > GNU/Linux 7(64-bit)" as highest possible Debian-version. The
> > documentation
> > > 
> > > > 
> > > > said to register the new systemvm-template before
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > updating the management server.
> > > > > > 
> > > > > > Maybe your issue is hot-fixed by registering a template with
> > Debian 7
> > > 
> > > > 
> > > > profile.
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Cheers,
> > > > > > 
> > > > > > - Stephan
> > > > > > 
> > > > > > 
> > > > > > Am Mittwoch, den 11.04.2018, 13:30 +0200 schrieb Martin Emrich:
>

Re: Egress rules not applied in 4.11.0

2018-04-11 Thread Rafael Weingärtner 
That is interesting. The VM is indeed in HVM mode.

On Wed, Apr 11, 2018 at 9:04 AM, Stephan Seitz 
wrote:

> # xe vm-param-list uuid=c1bcef11-ffc2-24bd-7c5e-0840fb4f8f49 | grep -e
> PV-legacy-args -e PV-boot -e HVM-boot -e HVM-shadow
>HVM-boot-policy ( RW): BIOS order
>HVM-boot-params (MRW): order: dc
>  HVM-shadow-multiplier ( RW): 1.000
> PV-legacy-args ( RW):
>  PV-bootloader ( RW):
> PV-bootloader-args ( RW):
>
> Am Mittwoch, den 11.04.2018, 09:00 -0300 schrieb Rafael Weingärtner:
> > Xen you execute the following command in your XenServer?
> >
> > >
> > > xe vm-param-list uuid=
> > >
> > Then, what is the content of these parameters?
> >
> >- PV-legacy-args
> >- PV-bootloader
> >- PV-bootloader-args
> >- HVM-boot-policy
> >- HVM-boot-params
> >- HVM-shadow-multiplier
> >
> >
> > It is just to make sure that the VM was indeed created using HVM mode.
> >
> > On Wed, Apr 11, 2018 at 8:55 AM, Stephan Seitz <
> s.se...@heinlein-support.de>
> > wrote:
> >
> > >
> > > Just tried a Debian 9 running on XenServer 6.5 SP1 with model "Other
> 2.6x
> > > Linux (64-bit)":
> > >
> > > # virt-what --version
> > > 1.15
> > > # virt-what
> > > hyperv
> > > xen
> > > xen-domU
> > > #
> > >
> > >
> > > Am Mittwoch, den 11.04.2018, 13:50 +0200 schrieb Stephan Seitz:
> > > >
> > > > AFAIK not for 6.5 SP1.
> > > > https://xen-orchestra.com/blog/meltdown-and-spectre-for-xenserver/
> shows
> > > that 7.x is fixed and gives the hint,
> > > >
> > > > that HVM guests are not affected (at least for spectre)
> > > >
> > > > https://support.citrix.com/article/CTX231390
> > > > " 6.2 SP1, and 6.5 SP1 versions of XenServer require extensive
> > > architectural changes to do so. Citrix is therefore not making
> hotfixes for
> > > these versions available to customers, and will continue to
> > > >
> > > > work with hardware vendors on other mitigation strategies. Customers
> on
> > > the 6.2 SP1 and 6.5 SP1 versions are strongly recommended to upgrade
> to a
> > > more recent version. "
> > > >
> > > >
> > > > I haven't tried it so far, but recent debian versions were kind of
> picky
> > > with different kinds of Xen virtualization as I've seen on "regular"
> VMs.
> > > >
> > > >
> > > >
> > > >
> > > > Am Mittwoch, den 11.04.2018, 11:42 + schrieb Paul Angus:
> > > > >
> > > > >
> > > > > virt-what will give 'xen-domU' for paravirtualized guests. Didn't
> > > XenServer make some kind of change around this as a Meltdown/Spectre
> > > migation?
> > > >
> > > > >
> > > > >
> > > > >
> > > > > Kind regards,
> > > > >
> > > > > Paul Angus
> > > > >
> > > > > paul.an...@shapeblue.com
> > > > > www.shapeblue.com
> > > > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > > > > @shapeblue
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > -Original Message-
> > > > > From: Stephan Seitz 
> > > > > Sent: 11 April 2018 12:38
> > > > > To: users@cloudstack.apache.org
> > > > > Subject: Re: Egress rules not applied in 4.11.0
> > > > >
> > > > > Hi martin,
> > > > >
> > > > > I've just read your issue on github and was wondering how you;ve
> been
> > > able to select Debian 9.
> > > >
> > > > >
> > > > > But maybe you did a fresh installation.
> > > > >
> > > > > We did an update from 4.9.2 to 4.11.0 and were able to select
> "Debian
> > > GNU/Linux 7(64-bit)" as highest possible Debian-version. The
> documentation
> > > said to register the new systemvm-template before
> > > >
> > > > >
> > > > > updating the management server.
> > > > >
> > > > > Maybe your issue is hot-fixed by registering a template with
> Debian 7
> > > profile.
> > > >
> > > > >
> > > > >
> > > > > Cheers,
> > > > >
> > > > > - Stephan
> > > > >
> > > > >
> > > > > Am Mittwoch, den 11.04.2018, 13:30 +0200 schrieb Martin Emrich:
> > > > > >
> > > > > >
> > > > > >
> > > > > > I investigated further, and opened an issue:
> > > > > > https://github.com/apache/cloudstack/issues/2561
> > > > > >
> > > > > > Cheers,
> > > > > >
> > > > > > Martin
> > > > > >
> > > > > >
> > > > > > Am 11.04.18 um 12:18 schrieb Martin Emrich:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Thanks... But I think something else is now broken, too...:
> > > > > > >
> > > > > > > The SystemVMs are now no longer being provisioned: They come up
> > > > > > > "empty" with "systemvm type=".
> > > > > > >
> > > > > > > I also deleted the Console Proxy VM, and the new one is plain,
> > > too...
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I tried with Git branch 4.11 (producing 4.11.1-SNAPSHOT RPMs),
> > > same
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > effect...
> > > > > > >
> > > > > > > Cheers,
> > > > > > >
> > > > > > > Martin
> > > > > > >
> > > > > > >
> > > > > > > Am 11.04.18 um 00:56 schrieb Rohit Yadav:
> > > > > > > >
> > > > > > > >
> > > > > > > >
>

Re: Egress rules not applied in 4.11.0

2018-04-11 Thread Stephan Seitz 
# xe vm-param-list uuid=c1bcef11-ffc2-24bd-7c5e-0840fb4f8f49 | grep -e 
PV-legacy-args -e PV-boot -e HVM-boot -e HVM-shadow
   HVM-boot-policy ( RW): BIOS order
   HVM-boot-params (MRW): order: dc
 HVM-shadow-multiplier ( RW): 1.000
PV-legacy-args ( RW): 
 PV-bootloader ( RW): 
PV-bootloader-args ( RW): 

Am Mittwoch, den 11.04.2018, 09:00 -0300 schrieb Rafael Weingärtner:
> Xen you execute the following command in your XenServer?
> 
> > 
> > xe vm-param-list uuid=
> > 
> Then, what is the content of these parameters?
> 
>    - PV-legacy-args
>    - PV-bootloader
>    - PV-bootloader-args
>    - HVM-boot-policy
>    - HVM-boot-params
>    - HVM-shadow-multiplier
> 
> 
> It is just to make sure that the VM was indeed created using HVM mode.
> 
> On Wed, Apr 11, 2018 at 8:55 AM, Stephan Seitz 
> wrote:
> 
> > 
> > Just tried a Debian 9 running on XenServer 6.5 SP1 with model "Other 2.6x
> > Linux (64-bit)":
> > 
> > # virt-what --version
> > 1.15
> > # virt-what
> > hyperv
> > xen
> > xen-domU
> > #
> > 
> > 
> > Am Mittwoch, den 11.04.2018, 13:50 +0200 schrieb Stephan Seitz:
> > > 
> > > AFAIK not for 6.5 SP1.
> > > https://xen-orchestra.com/blog/meltdown-and-spectre-for-xenserver/ shows
> > that 7.x is fixed and gives the hint,
> > > 
> > > that HVM guests are not affected (at least for spectre)
> > > 
> > > https://support.citrix.com/article/CTX231390
> > > " 6.2 SP1, and 6.5 SP1 versions of XenServer require extensive
> > architectural changes to do so. Citrix is therefore not making hotfixes for
> > these versions available to customers, and will continue to
> > > 
> > > work with hardware vendors on other mitigation strategies. Customers on
> > the 6.2 SP1 and 6.5 SP1 versions are strongly recommended to upgrade to a
> > more recent version. "
> > > 
> > > 
> > > I haven't tried it so far, but recent debian versions were kind of picky
> > with different kinds of Xen virtualization as I've seen on "regular" VMs.
> > > 
> > > 
> > > 
> > > 
> > > Am Mittwoch, den 11.04.2018, 11:42 + schrieb Paul Angus:
> > > > 
> > > > 
> > > > virt-what will give 'xen-domU' for paravirtualized guests. Didn't
> > XenServer make some kind of change around this as a Meltdown/Spectre
> > migation?
> > > 
> > > > 
> > > > 
> > > > 
> > > > Kind regards,
> > > > 
> > > > Paul Angus
> > > > 
> > > > paul.an...@shapeblue.com
> > > > www.shapeblue.com
> > > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > > > @shapeblue
> > > > 
> > > > 
> > > > 
> > > > 
> > > > -Original Message-
> > > > From: Stephan Seitz 
> > > > Sent: 11 April 2018 12:38
> > > > To: users@cloudstack.apache.org
> > > > Subject: Re: Egress rules not applied in 4.11.0
> > > > 
> > > > Hi martin,
> > > > 
> > > > I've just read your issue on github and was wondering how you;ve been
> > able to select Debian 9.
> > > 
> > > > 
> > > > But maybe you did a fresh installation.
> > > > 
> > > > We did an update from 4.9.2 to 4.11.0 and were able to select "Debian
> > GNU/Linux 7(64-bit)" as highest possible Debian-version. The documentation
> > said to register the new systemvm-template before
> > > 
> > > > 
> > > > updating the management server.
> > > > 
> > > > Maybe your issue is hot-fixed by registering a template with Debian 7
> > profile.
> > > 
> > > > 
> > > > 
> > > > Cheers,
> > > > 
> > > > - Stephan
> > > > 
> > > > 
> > > > Am Mittwoch, den 11.04.2018, 13:30 +0200 schrieb Martin Emrich:
> > > > > 
> > > > > 
> > > > > 
> > > > > I investigated further, and opened an issue:
> > > > > https://github.com/apache/cloudstack/issues/2561
> > > > > 
> > > > > Cheers,
> > > > > 
> > > > > Martin
> > > > > 
> > > > > 
> > > > > Am 11.04.18 um 12:18 schrieb Martin Emrich:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Thanks... But I think something else is now broken, too...:
> > > > > > 
> > > > > > The SystemVMs are now no longer being provisioned: They come up
> > > > > > "empty" with "systemvm type=".
> > > > > > 
> > > > > > I also deleted the Console Proxy VM, and the new one is plain,
> > too...
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > I tried with Git branch 4.11 (producing 4.11.1-SNAPSHOT RPMs),
> > same
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > effect...
> > > > > > 
> > > > > > Cheers,
> > > > > > 
> > > > > > Martin
> > > > > > 
> > > > > > 
> > > > > > Am 11.04.18 um 00:56 schrieb Rohit Yadav:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > Hi Martin,
> > > > > > > 
> > > > > > > 
> > > > > > > This is a known issue, a freshly restarted VR may not have the
> > > > > > > EGREE related tables which is why any rules will fail to apply.
> > As
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > a workaround, you can restart the network without selecting the
> > > > > > > cleanup option which will

Re: Egress rules not applied in 4.11.0

2018-04-11 Thread Rafael Weingärtner 
Xen you execute the following command in your XenServer?

> xe vm-param-list uuid=
>

Then, what is the content of these parameters?

   - PV-legacy-args
   - PV-bootloader
   - PV-bootloader-args
   - HVM-boot-policy
   - HVM-boot-params
   - HVM-shadow-multiplier


It is just to make sure that the VM was indeed created using HVM mode.

On Wed, Apr 11, 2018 at 8:55 AM, Stephan Seitz 
wrote:

> Just tried a Debian 9 running on XenServer 6.5 SP1 with model "Other 2.6x
> Linux (64-bit)":
>
> # virt-what --version
> 1.15
> # virt-what
> hyperv
> xen
> xen-domU
> #
>
>
> Am Mittwoch, den 11.04.2018, 13:50 +0200 schrieb Stephan Seitz:
> > AFAIK not for 6.5 SP1.
> > https://xen-orchestra.com/blog/meltdown-and-spectre-for-xenserver/ shows
> that 7.x is fixed and gives the hint,
> > that HVM guests are not affected (at least for spectre)
> >
> > https://support.citrix.com/article/CTX231390
> > " 6.2 SP1, and 6.5 SP1 versions of XenServer require extensive
> architectural changes to do so. Citrix is therefore not making hotfixes for
> these versions available to customers, and will continue to
> > work with hardware vendors on other mitigation strategies. Customers on
> the 6.2 SP1 and 6.5 SP1 versions are strongly recommended to upgrade to a
> more recent version. "
> >
> > I haven't tried it so far, but recent debian versions were kind of picky
> with different kinds of Xen virtualization as I've seen on "regular" VMs.
> >
> >
> >
> > Am Mittwoch, den 11.04.2018, 11:42 + schrieb Paul Angus:
> > >
> > > virt-what will give 'xen-domU' for paravirtualized guests. Didn't
> XenServer make some kind of change around this as a Meltdown/Spectre
> migation?
> > >
> > >
> > > Kind regards,
> > >
> > > Paul Angus
> > >
> > > paul.an...@shapeblue.com
> > > www.shapeblue.com
> > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > > @shapeblue
> > >
> > >
> > >
> > >
> > > -Original Message-
> > > From: Stephan Seitz 
> > > Sent: 11 April 2018 12:38
> > > To: users@cloudstack.apache.org
> > > Subject: Re: Egress rules not applied in 4.11.0
> > >
> > > Hi martin,
> > >
> > > I've just read your issue on github and was wondering how you;ve been
> able to select Debian 9.
> > > But maybe you did a fresh installation.
> > >
> > > We did an update from 4.9.2 to 4.11.0 and were able to select "Debian
> GNU/Linux 7(64-bit)" as highest possible Debian-version. The documentation
> said to register the new systemvm-template before
> > > updating the management server.
> > >
> > > Maybe your issue is hot-fixed by registering a template with Debian 7
> profile.
> > >
> > > Cheers,
> > >
> > > - Stephan
> > >
> > >
> > > Am Mittwoch, den 11.04.2018, 13:30 +0200 schrieb Martin Emrich:
> > > >
> > > >
> > > > I investigated further, and opened an issue:
> > > > https://github.com/apache/cloudstack/issues/2561
> > > >
> > > > Cheers,
> > > >
> > > > Martin
> > > >
> > > >
> > > > Am 11.04.18 um 12:18 schrieb Martin Emrich:
> > > > >
> > > > >
> > > > >
> > > > > Thanks... But I think something else is now broken, too...:
> > > > >
> > > > > The SystemVMs are now no longer being provisioned: They come up
> > > > > "empty" with "systemvm type=".
> > > > >
> > > > > I also deleted the Console Proxy VM, and the new one is plain,
> too...
> > > > >
> > > > > I tried with Git branch 4.11 (producing 4.11.1-SNAPSHOT RPMs),
> same
> > > > > effect...
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Martin
> > > > >
> > > > >
> > > > > Am 11.04.18 um 00:56 schrieb Rohit Yadav:
> > > > > >
> > > > > >
> > > > > >
> > > > > > Hi Martin,
> > > > > >
> > > > > >
> > > > > > This is a known issue, a freshly restarted VR may not have the
> > > > > > EGREE related tables which is why any rules will fail to apply.
> As
> > > > > > a workaround, you can restart the network without selecting the
> > > > > > cleanup option which will reconfigure the VR and add the egress
> table.
> > > > > >
> > > > > >
> > > > > > I've a fix in this PR:
> > > > > > https://github.com/apache/cloudstack/pull/2508/files#
> diff-2d3ea57d
> > > > > > fd9156e3983b1bb2d64abecd
> > > > > >
> > > > > >
> > > > > >
> > > > > > - Rohit
> > > > > >
> > > > > > 
> > > > > >
> > > > > >
> > > > > >
> > > > > > 
> > > > > > From: Martin Emrich 
> > > > > > Sent: Tuesday, April 10, 2018 2:13:57 PM
> > > > > > To: CloudStack-Users
> > > > > > Subject: Egress rules not applied in 4.11.0
> > > > > >
> > > > > > Hi!
> > > > > >
> > > > > > I upgraded my test cluster from 4.9 to 4.11. The default policy
> > > > > > for isolated networks is "Deny".
> > > > > >
> > > > > > But now, adding rules to allow egress traffic are not applied to
> > > > > > the virtual router. adding a 0.0.0.0/0 rule looks fine from the
> > > > > > UI, but does not appear in the iptables output on the VR.
> > > > > >
> > > > > > Any Ideas?
> > > > > >
> > > > > >

Re: Egress rules not applied in 4.11.0

2018-04-11 Thread Stephan Seitz 
Just tried a Debian 9 running on XenServer 6.5 SP1 with model "Other 2.6x Linux 
(64-bit)":

# virt-what --version
1.15
# virt-what
hyperv
xen
xen-domU
#


Am Mittwoch, den 11.04.2018, 13:50 +0200 schrieb Stephan Seitz:
> AFAIK not for 6.5 SP1.
> https://xen-orchestra.com/blog/meltdown-and-spectre-for-xenserver/ shows that 
> 7.x is fixed and gives the hint,
> that HVM guests are not affected (at least for spectre)
> 
> https://support.citrix.com/article/CTX231390
> " 6.2 SP1, and 6.5 SP1 versions of XenServer require extensive architectural 
> changes to do so. Citrix is therefore not making hotfixes for these versions 
> available to customers, and will continue to
> work with hardware vendors on other mitigation strategies. Customers on the 
> 6.2 SP1 and 6.5 SP1 versions are strongly recommended to upgrade to a more 
> recent version. "
> 
> I haven't tried it so far, but recent debian versions were kind of picky with 
> different kinds of Xen virtualization as I've seen on "regular" VMs.
> 
> 
> 
> Am Mittwoch, den 11.04.2018, 11:42 + schrieb Paul Angus:
> > 
> > virt-what will give 'xen-domU' for paravirtualized guests. Didn't XenServer 
> > make some kind of change around this as a Meltdown/Spectre migation? 
> > 
> > 
> > Kind regards,
> > 
> > Paul Angus
> > 
> > paul.an...@shapeblue.com 
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue
> >   
> >  
> > 
> > 
> > -Original Message-
> > From: Stephan Seitz  
> > Sent: 11 April 2018 12:38
> > To: users@cloudstack.apache.org
> > Subject: Re: Egress rules not applied in 4.11.0
> > 
> > Hi martin,
> > 
> > I've just read your issue on github and was wondering how you;ve been able 
> > to select Debian 9.
> > But maybe you did a fresh installation.
> > 
> > We did an update from 4.9.2 to 4.11.0 and were able to select "Debian 
> > GNU/Linux 7(64-bit)" as highest possible Debian-version. The documentation 
> > said to register the new systemvm-template before
> > updating the management server.
> > 
> > Maybe your issue is hot-fixed by registering a template with Debian 7 
> > profile.
> > 
> > Cheers,
> > 
> > - Stephan
> > 
> > 
> > Am Mittwoch, den 11.04.2018, 13:30 +0200 schrieb Martin Emrich:
> > > 
> > > 
> > > I investigated further, and opened an issue:
> > > https://github.com/apache/cloudstack/issues/2561
> > > 
> > > Cheers,
> > > 
> > > Martin
> > > 
> > > 
> > > Am 11.04.18 um 12:18 schrieb Martin Emrich:
> > > > 
> > > > 
> > > > 
> > > > Thanks... But I think something else is now broken, too...:
> > > > 
> > > > The SystemVMs are now no longer being provisioned: They come up 
> > > > "empty" with "systemvm type=".
> > > > 
> > > > I also deleted the Console Proxy VM, and the new one is plain, too...
> > > > 
> > > > I tried with Git branch 4.11 (producing 4.11.1-SNAPSHOT RPMs), same 
> > > > effect...
> > > > 
> > > > Cheers,
> > > > 
> > > > Martin
> > > > 
> > > > 
> > > > Am 11.04.18 um 00:56 schrieb Rohit Yadav:
> > > > > 
> > > > > 
> > > > > 
> > > > > Hi Martin,
> > > > > 
> > > > > 
> > > > > This is a known issue, a freshly restarted VR may not have the 
> > > > > EGREE related tables which is why any rules will fail to apply. As 
> > > > > a workaround, you can restart the network without selecting the 
> > > > > cleanup option which will reconfigure the VR and add the egress table.
> > > > > 
> > > > > 
> > > > > I've a fix in this PR:
> > > > > https://github.com/apache/cloudstack/pull/2508/files#diff-2d3ea57d
> > > > > fd9156e3983b1bb2d64abecd
> > > > > 
> > > > > 
> > > > > 
> > > > > - Rohit
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > From: Martin Emrich 
> > > > > Sent: Tuesday, April 10, 2018 2:13:57 PM
> > > > > To: CloudStack-Users
> > > > > Subject: Egress rules not applied in 4.11.0
> > > > > 
> > > > > Hi!
> > > > > 
> > > > > I upgraded my test cluster from 4.9 to 4.11. The default policy 
> > > > > for isolated networks is "Deny".
> > > > > 
> > > > > But now, adding rules to allow egress traffic are not applied to 
> > > > > the virtual router. adding a 0.0.0.0/0 rule looks fine from the 
> > > > > UI, but does not appear in the iptables output on the VR.
> > > > > 
> > > > > Any Ideas?
> > > > > 
> > > > > Thanks
> > > > > 
> > > > > Martin
> > > > > 
> > > > > 
> > > > > rohit.ya...@shapeblue.com
> > > > > www.shapeblue.com
> > > > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
> > > > > 
> > Mit freundlichen Grüßen,
> > 
> > Stephan Seitz
> > 
> > --
> > 
> > Heinlein Support GmbH
> > Schwedter Str. 8/9b, 10119 Berlin
> > 
> > http://www.heinlein-support.de
> > 
> > Tel: 030 / 405051-44
> > Fax: 030 / 405051-19
> > 
> > Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht 
> > Berlin-Charlottenburg,
> > Geschäftsführer: Peer Heinlein -- Sitz: Berlin
> > 
> > 
> Mit freundlichen Grüßen,

Re: Egress rules not applied in 4.11.0

2018-04-11 Thread Stephan Seitz 
AFAIK not for 6.5 SP1.
https://xen-orchestra.com/blog/meltdown-and-spectre-for-xenserver/ shows that 
7.x is fixed and gives the hint,
that HVM guests are not affected (at least for spectre)

https://support.citrix.com/article/CTX231390
" 6.2 SP1, and 6.5 SP1 versions of XenServer require extensive architectural 
changes to do so. Citrix is therefore not making hotfixes for these versions 
available to customers, and will continue to
work with hardware vendors on other mitigation strategies. Customers on the 6.2 
SP1 and 6.5 SP1 versions are strongly recommended to upgrade to a more recent 
version. "

I haven't tried it so far, but recent debian versions were kind of picky with 
different kinds of Xen virtualization as I've seen on "regular" VMs.



Am Mittwoch, den 11.04.2018, 11:42 + schrieb Paul Angus:
> virt-what will give 'xen-domU' for paravirtualized guests. Didn't XenServer 
> make some kind of change around this as a Meltdown/Spectre migation? 
> 
> 
> Kind regards,
> 
> Paul Angus
> 
> paul.an...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>   
>  
> 
> 
> -Original Message-
> From: Stephan Seitz  
> Sent: 11 April 2018 12:38
> To: users@cloudstack.apache.org
> Subject: Re: Egress rules not applied in 4.11.0
> 
> Hi martin,
> 
> I've just read your issue on github and was wondering how you;ve been able to 
> select Debian 9.
> But maybe you did a fresh installation.
> 
> We did an update from 4.9.2 to 4.11.0 and were able to select "Debian 
> GNU/Linux 7(64-bit)" as highest possible Debian-version. The documentation 
> said to register the new systemvm-template before
> updating the management server.
> 
> Maybe your issue is hot-fixed by registering a template with Debian 7 profile.
> 
> Cheers,
> 
> - Stephan
> 
> 
> Am Mittwoch, den 11.04.2018, 13:30 +0200 schrieb Martin Emrich:
> > 
> > I investigated further, and opened an issue:
> > https://github.com/apache/cloudstack/issues/2561
> > 
> > Cheers,
> > 
> > Martin
> > 
> > 
> > Am 11.04.18 um 12:18 schrieb Martin Emrich:
> > > 
> > > 
> > > Thanks... But I think something else is now broken, too...:
> > > 
> > > The SystemVMs are now no longer being provisioned: They come up 
> > > "empty" with "systemvm type=".
> > > 
> > > I also deleted the Console Proxy VM, and the new one is plain, too...
> > > 
> > > I tried with Git branch 4.11 (producing 4.11.1-SNAPSHOT RPMs), same 
> > > effect...
> > > 
> > > Cheers,
> > > 
> > > Martin
> > > 
> > > 
> > > Am 11.04.18 um 00:56 schrieb Rohit Yadav:
> > > > 
> > > > 
> > > > Hi Martin,
> > > > 
> > > > 
> > > > This is a known issue, a freshly restarted VR may not have the 
> > > > EGREE related tables which is why any rules will fail to apply. As 
> > > > a workaround, you can restart the network without selecting the 
> > > > cleanup option which will reconfigure the VR and add the egress table.
> > > > 
> > > > 
> > > > I've a fix in this PR:
> > > > https://github.com/apache/cloudstack/pull/2508/files#diff-2d3ea57d
> > > > fd9156e3983b1bb2d64abecd
> > > > 
> > > > 
> > > > 
> > > > - Rohit
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > From: Martin Emrich 
> > > > Sent: Tuesday, April 10, 2018 2:13:57 PM
> > > > To: CloudStack-Users
> > > > Subject: Egress rules not applied in 4.11.0
> > > > 
> > > > Hi!
> > > > 
> > > > I upgraded my test cluster from 4.9 to 4.11. The default policy 
> > > > for isolated networks is "Deny".
> > > > 
> > > > But now, adding rules to allow egress traffic are not applied to 
> > > > the virtual router. adding a 0.0.0.0/0 rule looks fine from the 
> > > > UI, but does not appear in the iptables output on the VR.
> > > > 
> > > > Any Ideas?
> > > > 
> > > > Thanks
> > > > 
> > > > Martin
> > > > 
> > > > 
> > > > rohit.ya...@shapeblue.com
> > > > www.shapeblue.com
> > > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
> > > > 
> Mit freundlichen Grüßen,
> 
> Stephan Seitz
> 
> --
> 
> Heinlein Support GmbH
> Schwedter Str. 8/9b, 10119 Berlin
> 
> http://www.heinlein-support.de
> 
> Tel: 030 / 405051-44
> Fax: 030 / 405051-19
> 
> Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht Berlin-Charlottenburg,
> Geschäftsführer: Peer Heinlein -- Sitz: Berlin
> 
> 
Mit freundlichen Grüßen,

Stephan Seitz

--

Heinlein Support GmbH
Schwedter Str. 8/9b, 10119 Berlin

http://www.heinlein-support.de

Tel: 030 / 405051-44
Fax: 030 / 405051-19

Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht
Berlin-Charlottenburg,
Geschäftsführer: Peer Heinlein -- Sitz: Berlin




signature.asc
Description: This is a digitally signed message part

RE: Egress rules not applied in 4.11.0

2018-04-11 Thread Paul Angus 
virt-what will give 'xen-domU' for paravirtualized guests. Didn't XenServer 
make some kind of change around this as a Meltdown/Spectre migation? 


Kind regards,

Paul Angus

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


-Original Message-
From: Stephan Seitz  
Sent: 11 April 2018 12:38
To: users@cloudstack.apache.org
Subject: Re: Egress rules not applied in 4.11.0

Hi martin,

I've just read your issue on github and was wondering how you;ve been able to 
select Debian 9.
But maybe you did a fresh installation.

We did an update from 4.9.2 to 4.11.0 and were able to select "Debian GNU/Linux 
7(64-bit)" as highest possible Debian-version. The documentation said to 
register the new systemvm-template before updating the management server.

Maybe your issue is hot-fixed by registering a template with Debian 7 profile.

Cheers,

- Stephan


Am Mittwoch, den 11.04.2018, 13:30 +0200 schrieb Martin Emrich:
> I investigated further, and opened an issue:
> https://github.com/apache/cloudstack/issues/2561
> 
> Cheers,
> 
> Martin
> 
> 
> Am 11.04.18 um 12:18 schrieb Martin Emrich:
> > 
> > Thanks... But I think something else is now broken, too...:
> > 
> > The SystemVMs are now no longer being provisioned: They come up 
> > "empty" with "systemvm type=".
> > 
> > I also deleted the Console Proxy VM, and the new one is plain, too...
> > 
> > I tried with Git branch 4.11 (producing 4.11.1-SNAPSHOT RPMs), same 
> > effect...
> > 
> > Cheers,
> > 
> > Martin
> > 
> > 
> > Am 11.04.18 um 00:56 schrieb Rohit Yadav:
> > > 
> > > Hi Martin,
> > > 
> > > 
> > > This is a known issue, a freshly restarted VR may not have the 
> > > EGREE related tables which is why any rules will fail to apply. As 
> > > a workaround, you can restart the network without selecting the 
> > > cleanup option which will reconfigure the VR and add the egress table.
> > > 
> > > 
> > > I've a fix in this PR:
> > > https://github.com/apache/cloudstack/pull/2508/files#diff-2d3ea57d
> > > fd9156e3983b1bb2d64abecd
> > > 
> > > 
> > > 
> > > - Rohit
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > From: Martin Emrich 
> > > Sent: Tuesday, April 10, 2018 2:13:57 PM
> > > To: CloudStack-Users
> > > Subject: Egress rules not applied in 4.11.0
> > > 
> > > Hi!
> > > 
> > > I upgraded my test cluster from 4.9 to 4.11. The default policy 
> > > for isolated networks is "Deny".
> > > 
> > > But now, adding rules to allow egress traffic are not applied to 
> > > the virtual router. adding a 0.0.0.0/0 rule looks fine from the 
> > > UI, but does not appear in the iptables output on the VR.
> > > 
> > > Any Ideas?
> > > 
> > > Thanks
> > > 
> > > Martin
> > > 
> > > 
> > > rohit.ya...@shapeblue.com
> > > www.shapeblue.com
> > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
> > > 
Mit freundlichen Grüßen,

Stephan Seitz

--

Heinlein Support GmbH
Schwedter Str. 8/9b, 10119 Berlin

http://www.heinlein-support.de

Tel: 030 / 405051-44
Fax: 030 / 405051-19

Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht Berlin-Charlottenburg,
Geschäftsführer: Peer Heinlein -- Sitz: Berlin

Re: Egress rules not applied in 4.11.0

2018-04-11 Thread Stephan Seitz 
Hi martin,

I've just read your issue on github and was wondering how you;ve been able to 
select Debian 9.
But maybe you did a fresh installation.

We did an update from 4.9.2 to 4.11.0 and were able to select "Debian GNU/Linux 
7(64-bit)" as
highest possible Debian-version. The documentation said to register the new 
systemvm-template
before updating the management server.

Maybe your issue is hot-fixed by registering a template with Debian 7 profile.

Cheers,

- Stephan


Am Mittwoch, den 11.04.2018, 13:30 +0200 schrieb Martin Emrich:
> I investigated further, and opened an issue: 
> https://github.com/apache/cloudstack/issues/2561
> 
> Cheers,
> 
> Martin
> 
> 
> Am 11.04.18 um 12:18 schrieb Martin Emrich:
> > 
> > Thanks... But I think something else is now broken, too...:
> > 
> > The SystemVMs are now no longer being provisioned: They come up 
> > "empty" with "systemvm type=".
> > 
> > I also deleted the Console Proxy VM, and the new one is plain, too...
> > 
> > I tried with Git branch 4.11 (producing 4.11.1-SNAPSHOT RPMs), same 
> > effect...
> > 
> > Cheers,
> > 
> > Martin
> > 
> > 
> > Am 11.04.18 um 00:56 schrieb Rohit Yadav:
> > > 
> > > Hi Martin,
> > > 
> > > 
> > > This is a known issue, a freshly restarted VR may not have the EGREE 
> > > related tables which is why any rules will fail to apply. As a 
> > > workaround, you can restart the network without selecting the cleanup 
> > > option which will reconfigure the VR and add the egress table.
> > > 
> > > 
> > > I've a fix in this PR: 
> > > https://github.com/apache/cloudstack/pull/2508/files#diff-2d3ea57dfd9156e3983b1bb2d64abecd
> > > 
> > > 
> > > 
> > > - Rohit
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > From: Martin Emrich 
> > > Sent: Tuesday, April 10, 2018 2:13:57 PM
> > > To: CloudStack-Users
> > > Subject: Egress rules not applied in 4.11.0
> > > 
> > > Hi!
> > > 
> > > I upgraded my test cluster from 4.9 to 4.11. The default policy for
> > > isolated networks is "Deny".
> > > 
> > > But now, adding rules to allow egress traffic are not applied to the
> > > virtual router. adding a 0.0.0.0/0 rule looks fine from the UI, but does
> > > not appear in the iptables output on the VR.
> > > 
> > > Any Ideas?
> > > 
> > > Thanks
> > > 
> > > Martin
> > > 
> > > 
> > > rohit.ya...@shapeblue.com
> > > www.shapeblue.com
> > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > > @shapeblue
> > > 
Mit freundlichen Grüßen,

Stephan Seitz

--

Heinlein Support GmbH
Schwedter Str. 8/9b, 10119 Berlin

http://www.heinlein-support.de

Tel: 030 / 405051-44
Fax: 030 / 405051-19

Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht
Berlin-Charlottenburg,
Geschäftsführer: Peer Heinlein -- Sitz: Berlin



signature.asc
Description: This is a digitally signed message part

Re: Egress rules not applied in 4.11.0

2018-04-11 Thread Martin Emrich 
I investigated further, and opened an issue: 
https://github.com/apache/cloudstack/issues/2561


Cheers,

Martin


Am 11.04.18 um 12:18 schrieb Martin Emrich:

Thanks... But I think something else is now broken, too...:

The SystemVMs are now no longer being provisioned: They come up 
"empty" with "systemvm type=".


I also deleted the Console Proxy VM, and the new one is plain, too...

I tried with Git branch 4.11 (producing 4.11.1-SNAPSHOT RPMs), same 
effect...


Cheers,

Martin


Am 11.04.18 um 00:56 schrieb Rohit Yadav:

Hi Martin,


This is a known issue, a freshly restarted VR may not have the EGREE 
related tables which is why any rules will fail to apply. As a 
workaround, you can restart the network without selecting the cleanup 
option which will reconfigure the VR and add the egress table.



I've a fix in this PR: 
https://github.com/apache/cloudstack/pull/2508/files#diff-2d3ea57dfd9156e3983b1bb2d64abecd




- Rohit






From: Martin Emrich 
Sent: Tuesday, April 10, 2018 2:13:57 PM
To: CloudStack-Users
Subject: Egress rules not applied in 4.11.0

Hi!

I upgraded my test cluster from 4.9 to 4.11. The default policy for
isolated networks is "Deny".

But now, adding rules to allow egress traffic are not applied to the
virtual router. adding a 0.0.0.0/0 rule looks fine from the UI, but does
not appear in the iptables output on the VR.

Any Ideas?

Thanks

Martin


rohit.ya...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue

Re: Egress rules not applied in 4.11.0

2018-04-11 Thread Martin Emrich 

Thanks... But I think something else is now broken, too...:

The SystemVMs are now no longer being provisioned: They come up "empty" 
with "systemvm type=".


I also deleted the Console Proxy VM, and the new one is plain, too...

I tried with Git branch 4.11 (producing 4.11.1-SNAPSHOT RPMs), same 
effect...


Cheers,

Martin


Am 11.04.18 um 00:56 schrieb Rohit Yadav:

Hi Martin,


This is a known issue, a freshly restarted VR may not have the EGREE related 
tables which is why any rules will fail to apply. As a workaround, you can 
restart the network without selecting the cleanup option which will reconfigure 
the VR and add the egress table.


I've a fix in this PR: 
https://github.com/apache/cloudstack/pull/2508/files#diff-2d3ea57dfd9156e3983b1bb2d64abecd



- Rohit






From: Martin Emrich 
Sent: Tuesday, April 10, 2018 2:13:57 PM
To: CloudStack-Users
Subject: Egress rules not applied in 4.11.0

Hi!

I upgraded my test cluster from 4.9 to 4.11. The default policy for
isolated networks is "Deny".

But now, adding rules to allow egress traffic are not applied to the
virtual router. adding a 0.0.0.0/0 rule looks fine from the UI, but does
not appear in the iptables output on the VR.

Any Ideas?

Thanks

Martin


rohit.ya...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue

AW: XenServer Storage Live Migration between pools

2018-04-11 Thread Swen - swen.io 
We found the root cause of our problem. The cluster was dedicated to a
domain and the VM was not part of this domain. CS is not giving any error in
the UI when you try this. I will check the latest version of CS for this.

Best regards,
Swen

-Ursprüngliche Nachricht-
Von: Swen - swen.io [mailto:m...@swen.io] 
Gesendet: Dienstag, 10. April 2018 09:29
An: users@cloudstack.apache.org
Betreff: XenServer Storage Live Migration between pools

Hi all,

we added a new XenServer 6.5 SP1 cluster (pool) to our CS installation. When
we do a live migration between pools we run into a problem with the VM. The
migration itself is working fine and the VM is reachable all the time. I can
see in XenCenter that the same network has been created on the new pool for
the VM. But when I stop and start the VM CS tells me that it was successful
but the VM is not starting on the XenServer. In XenServer logfiles I can see
problems with attaching VIF (virtual network interface) to the VM. Does
somebody else run into this problem?

As far as I can see there are no errors in the management server log.

best regards,
Swen