From users-return-32747-apmail-cloudstack-users-archive=cloudstack.apache.org@cloudstack.apache.org Fri May 3 10:15:35 2019 Return-Path: X-Original-To: apmail-cloudstack-users-archive@www.apache.org Delivered-To: apmail-cloudstack-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by minotaur.apache.org (Postfix) with SMTP id 34DFD19C52 for ; Fri, 3 May 2019 10:15:35 +0000 (UTC) Received: (qmail 29348 invoked by uid 500); 3 May 2019 10:15:32 -0000 Delivered-To: apmail-cloudstack-users-archive@cloudstack.apache.org Received: (qmail 29321 invoked by uid 500); 3 May 2019 10:15:32 -0000 Mailing-List: contact users-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@cloudstack.apache.org Delivered-To: mailing list users@cloudstack.apache.org Received: (qmail 29301 invoked by uid 99); 3 May 2019 10:15:27 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 May 2019 10:15:27 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 21640C23A4 for ; Fri, 3 May 2019 10:15:27 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KAM_SHORT=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (1024-bit key) header.d=li.nux.ro Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id 5uDpAl3oniKS for ; Fri, 3 May 2019 10:15:24 +0000 (UTC) Received: from mailserver.lastdot.org (mailserver.lastdot.org [31.193.175.196]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 2B38E5F232 for ; Fri, 3 May 2019 10:15:24 +0000 (UTC) Received: from localhost (localhost [IPv6:::1]) by mailserver.lastdot.org (Postfix) with ESMTP id BAFD52FF677 for ; Fri, 3 May 2019 11:15:16 +0100 (BST) Received: from mailserver.lastdot.org ([IPv6:::1]) by localhost (mailserver.lastdot.org [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id ocjyInusUQES for ; Fri, 3 May 2019 11:15:14 +0100 (BST) Received: from localhost (localhost [IPv6:::1]) by mailserver.lastdot.org (Postfix) with ESMTP id 7ABEB2FF678 for ; Fri, 3 May 2019 11:15:14 +0100 (BST) DKIM-Filter: OpenDKIM Filter v2.10.3 mailserver.lastdot.org 7ABEB2FF678 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=li.nux.ro; s=C605E3A6-F3C6-11E3-AEB0-DFF9218DCAC4; t=1556878514; bh=1x9WdFX9T+3bSKOJtAmCYr+RxCgycmpBEc24Q/rAi00=; h=Date:From:To:Message-ID:MIME-Version; b=EprAqkp2Yn9RRKh/Jy1o7/in5eqDg65xxO9kpiqyLDZG/9ZiJm1oYvfMrDBDH7kjh onavofYknMSb7POGcBkeY7yj0xZxsnhchJ5eVxO4Jm9G08CicJ+cpVItXDShGMpJAy S3kT+nj4zYY98EGOr3x0ju1H/6XkZeb1BUcQw+ys= X-Virus-Scanned: amavisd-new at mailserver.lastdot.org Received: from mailserver.lastdot.org ([IPv6:::1]) by localhost (mailserver.lastdot.org [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id 6LvvBCprl3du for ; Fri, 3 May 2019 11:15:14 +0100 (BST) Received: from mailserver.lastdot.org (mailserver.lastdot.org [31.193.175.196]) by mailserver.lastdot.org (Postfix) with ESMTP id 019A52FF677 for ; Fri, 3 May 2019 11:15:13 +0100 (BST) Date: Fri, 3 May 2019 11:15:10 +0100 (BST) From: Nux! To: users Message-ID: <1613517467.20001.1556878509994.JavaMail.zimbra@li.nux.ro> In-Reply-To: References: Subject: Re: Restricting IP usage & Upgrading CloudStack & Live storage migration MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.7.0_GA_1659 (ZimbraWebClient - FF60 (Linux)/8.7.0_GA_1659) Thread-Topic: Restricting IP usage & Upgrading CloudStack & Live storage migration Thread-Index: AQHVADrwZSuBxrROCECI1sHW8IZcT6ZWlrkAgAAIAYCAAAHtQPxZGCPy Hi, In Proxmox you could use the "IP Filter" option + "Firewall in" options to restrict IP address stealing. /offtopic If you go for a Cloudstack Advanced Zone with Security Groups, then your VMs can get 1 or more public IP addresses and this is enforced automatically via iptables and ebtables; other VMs won't be able to use the IPs. Beware of limitations though, IPv6 support is not really there yet and you can only connect a VM into one network, so if you want to have a 2nd "private" network, that's not yet possible with Cloudstack. If you go for a vanilla Advanced Zone then you connect your VMs into a network (own VLAN) that is served by a virtual appliance (virtual router running debian, doing NAT etc basically). IP stealign is also not possible. You can connect the VM in as many networks you want, but do bare in mind you'll likely be dealing with private IPs and NAT a lot, but you have more options here. Last I checked it was possible to have local live migrations with KVM, I guess that would be your target platform. Do take your time and test, there is a learning curve to this, more than with Proxmox, but less than with Openstack. HTH -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro ----- Original Message ----- > From: "Paul Angus" > To: "users" > Sent: Wednesday, 1 May, 2019 20:19:17 > Subject: RE: Restricting IP usage & Upgrading CloudStack & Live storage migration > - The models are 'native' if you like, definitely not workarounds. > > - CloudStack is an orchestrator, it largely relies on the abilities of the > hypervisors that it orchestrates. We add a little secret sauce here and there, > but when it comes to basic hypervisor functions, we leave it up to the > hypervisor. > > > paul.angus@shapeblue.com > www.shapeblue.com > Amadeus House, Floral Street, London WC2E 9DPUK > @shapeblue > > > > > -----Original Message----- > From: Razvan Rosca > Sent: 01 May 2019 19:57 > To: users@cloudstack.apache.org > Subject: Re: Restricting IP usage & Upgrading CloudStack & Live storage > migration > > Hey Paul, > > Thank you for your fast reply! > >> There are a few different models that you can use. > Do any of these models work "by default", or they are "workarounds" > (similar to Proxmox / LXC)? Aka is this a native/direct solution that can be > applied in the VM creation flow? > >> Yes CloudStack does support Xen Live Storage migration > I was referring to something *similar* with Xen Live Storage migration, not Xen > Live Storage "per se". Aka migrate a VM from a CloudStack node to another > CloudStack node, natively, live, without using a central storage. > > Thank you, > Razvan Rosca > > Skype: razvan.rosca > Tel: +40 731 059 660 > Linkedin: https://www.linkedin.com/in/razvanrosca/ > Facebook: https://fb.com/razvanrosca.com > > > On Wed, May 1, 2019 at 9:50 PM Paul Angus wrote: > >> Hi Razvan, >> >> - There are a few different models that you can use. But in short - 'yes' >> you can have a model where an IP is allocated to a VM and the VM keeps it. >> - No, we spend a lot of time making sure that upgrades between all >> versions work. Our versioning system requires that the API is backward >> compatible and we can only break that with a major version upgrade >> (say 4.x to 5.x )and that hasn't happened under Apache yet >> - Yes CloudStack does support Xen Live Storage migration - >> http://docs.cloudstack.apache.org/en/latest/adminguide/storage.html?hi >> ghlight=live%20storage#storage-overview >> >> Cheers >> >> Paul. >> >> >> >> paul.angus@shapeblue.com >> www.shapeblue.com >> Amadeus House, Floral Street, London WC2E 9DPUK @shapeblue >> >> >> >> >> -----Original Message----- >> From: Razvan Rosca >> Sent: 01 May 2019 17:28 >> To: users@cloudstack.apache.org >> Subject: Restricting IP usage & Upgrading CloudStack & Live storage >> migration >> >> Hello, >> >> We're thinking about switching from our current Xen+Proxmox setup into >> something more "advanced", and we're really considering CloudStack as one >> of our best/main candidates. >> >> Right off the bat here are the first questions: >> >> - in our current setup users can freely use each other's IP address, >> because the software stack doesn't enforce any limits (or requires us to >> manually edit stuff each time a VM is created). Does CloudStack have the >> same behavior? What we need is kinda simple: allow a specific VM to use >> a >> specific IP, and only that IP. >> - does CloudStack have the same "no-upgrade" policy as OpenStack? >> Ugrading OpenStack was/is nearly impossible, so I'm wondering if this is >> the case with CloudStack as well. >> - does CloudStack support "live-migration" between local storages? Xen >> does it, and does it really well. Again, I'm referring to local storage >> (local HDD/SSD/NVMe), not a central Ceph/Gluster/NFS store. >> >> Thank you, >> Razvan Rosca >> >> Skype: razvan.rosca >> Tel: +40 731 059 660 >> Linkedin: https://www.linkedin.com/in/razvanrosca/ >> Facebook: https://fb.com/razvanrosca.com