Hello, Community! I like idea about VM based Anchor's. For example in Russia we have so much companies who really want to host RIPE Anchor hosting but it's really hard due to so much bureaucracy for computer hardware import. It's really sophisticated and long task. VM based Anchors could help in this case. But they should be designated as "second-rate monitoring". So somebody who interested in monitoring over non-so-reliable-vm's could use they. Actually, this VM's should "mine" less points than full-size-Anchor. We could select some unified way to run VM's. I prefer VmWare because it's: 1) Free 2) Simple to deploy 3) Mature 4) Very simple VM deploy Xen, KVM are pretty too but they are based on non standard linux distributions and it could be a configuration issue. OpenVZ/Docker and LXC should be avoided because (actually I have so much experience with they and I'm not a technology hater) they are not offer dedicated service and not isolated perfectly from each other processes. On Tue, Nov 10, 2015 at 11:56 AM, Gert Doering <gert@space.net> wrote:
Hi,
On Tue, Nov 10, 2015 at 09:33:01AM +0100, Daniel Karrenberg wrote:
From my personal, informal assessment I advise against supporting VMs. I recommend a thorough assessment of the data quality, the costs and the effects on RIPE Atlas as a whole before diving into soloutioneering.
From experience running a recursive DNS on a VM platform, I'd also speak against supporting VMs. Unpredictable load elsewhere on the same host can (and does) lead to UDP/ICMP packet loss, which the "Atlas VM" won't be able to differenciate from "something on the path is broken/lossy".
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
-- Sincerely yours, Pavel Odintsov