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 +0000 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 <s.se...@heinlein-support.de> > > 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 > > > > > > > > > > <https://cloudstack.apache.org> > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > From: Martin Emrich <martin.emr...@empolis.com> > > > > > 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 > > 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
