[atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)

So, is this mean that we can build our soekris hardware by our self?
(we don't have to import any soekris from outside).
If this true, then it will be an opportunity for any network that want
to host an anchor but limited by import issues.

On Tue, Nov 10, 2015 at 5:39 PM, Pavel Odintsov
<pavel.odintsov at gmail.com> wrote:
> Hello!
>
> Maybe we could fix import issues with some vendor?
>
> We have really huge and good shop of network hardware here:
> http://shop.nag.ru If they could offer Soekris platform could be fine.
>
> On Tue, Nov 10, 2015 at 1:30 PM, Daniel Karrenberg
> <daniel.karrenberg at ripe.net> wrote:
>> Pavel,
>>
>> it appears that my information is out-dated. You are right one needs to
>> import them these days. I realise that this is awkward and expensive,
>> but it appears to be possible.
>>
>> Maybe rather than wasting time on VMs we should consider a new type of
>> anchor which is more readily available everywhere than the Soekris.
>> Personally I would go in the direction of Ubiquity Edge Routers or
>> Mikrotik routers which I know for sure are available in Russia and also
>> widely available around the world. Do you have suggestions?
>>
>> Daniel
>>
>> On 10.11.15 10:49 , Pavel Odintsov wrote:
>>> Hello!
>>>
>>> Awesome! Could you share where we could bought it? I will share this
>>> information with local community.
>>>
>>> On Tue, Nov 10, 2015 at 12:36 PM, Daniel Karrenberg
>>> <daniel.karrenberg at ripe.net> wrote:
>>>> At this time are 485 connected probes and two connected anchors in
>>>> Russia. As far as I know Soekris boxes can be bought in Russia.
>>>>
>>>> Daniel
>>>>
>>>> On 10.11.15 10:07 , Pavel Odintsov wrote:
>>>>> 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 at 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
>