On 02/27/2012 05:06 AM, Ayal Baron wrote:
> ----- Original Message -----
>> Perry Myers píše v St 22. 02. 2012 v 11:54 -0500:
>>>>> As answered in the other response, there are kernel command line
>>>>> parameters to set the management_server. Since this will likely
>>>>> be in a
>>>>> pxe environment, setting the pxe profile to include
>>>>> management_server=<engine_url> should be fine.
>>>> I agree it's a valid solution as long as you assume this is
>>>> for PXE only use case.
>>> Not necessarily...
>>> Take the ISO/USB Stick and you can embed the kargs into the ISO/USB
>>> itself so that it always boots with that mgmt server arg
>>> This actually also enables use of 'stateless' combined with static
>>> addressing as well. As you can create a USB Stick and embed the
>>> for the NIC configuration, rsyslog config, etc, etc.
>>>>> Another solution could be to setup a specific DNS SRV record
>>>>> that points
>>>>> to the ovirt-engine and have node automatically query that for
>>>> This was discussed in the past and for some reason not
>>> Concerns about security, iirc. Assumption that someone could
>>> hijack the
>>> DNS SRV record and provide a man-in-the-middle oVirt Engine server.
>> What about DNSSEC validation for DNS records in node?
> This will require more than just changes to the registration process
> and it's quite difficult to track the required changes here on email.
> Let's setup a call to discuss this and try to capture the list of
> issues we already know about (I'm sure we'll discover more once we
> actually try to do this).
I'm fine with setting up a call as long as we publish the dial in info
on list so that folks in the community can join in if they are interested.
Also, stateless design has been a topic on the oVirt Node weekly IRC
meeting for the last few weeks as we flesh out design issues, etc. I'd
be happy for folks from other teams to join in there
> To play devil's advocate though, I know there is interest, but I
> really don't understand the incentive.
> What is the *problem* you're trying to solve here (stateless is a solution)
The primary motivation is diskless nodes. Being able to purchase mass
quantities of servers and not needing to put any sort of storage in
them. Since disks have much lower MTBF than other components (aside
from fans probably), diskless servers require less maintenance.
As mentioned earlier in this thread, diskless would mean no swap and no
local storage. Both of which are suitable if you're using SAN
(FC/iSCSI) based storage for VM images and if memory overcommit is not
The argument for 'stateless without diskless' is a little more tenuous,
however, if you're going to do stateless to get support for diskless,
adding in support for local VM image storage and swap is fairly trivial.
Andy, I think you've got some opinions here, care to weigh in?
Otherwise if there is continued pushback on this feature, I'm happy to
not waste effort on it. There are other things we can work on :)
vdsm-devel mailing list