OpenSLX

sorry schreibe Blödsinn, nat/bridged steht ja im XML drin. sollte es noch einen override via slxconfig geben? vielleicht besser nicht;)

Was denn jetzt? Zuerst Hü, und dann Hott?

Soll ich das Ticket schließen?? Warum ist das überhaupt an mich zugewiesen?

Wenn ich das obere zusammenfasse brauchen wir also eher eine Möglichkeit, die MAC-Adressen dynamisch zu setzen...

Derzeit besteht noch das Problem, dass der DHCP eine Kombination aus dynamischen IPs (Range) und festgelegten MACs nicht kann/konnte. Für Bridge (das geht ja schon alles mit der Einstellung via *.xml) besteht ganz klar das Problem mit dem geeigneten Addresspool. Eine mögliche Alternativlösung wäre, Packet-Forwarding für bestimmte Ports einzurichten (evtl. als Datei für rootfs/etc/vmware/... festlegen).

Bastian wrote:

Was denn jetzt? Zuerst Hü, und dann Hott?

Hate vergessen, dass es ja sowas schon gibt. Wird es denn von runvmware... ausgewertet? Oder ist immer nat? Sonst müßte man das anpassen.

Soll ich das Ticket schließen?? Warum ist das überhaupt an mich zugewiesen?

Keine Angst, da Volker krank ist, habe ich dich mal eingetragen, da ich nicht weiß wer was ausliest, schreibt.

Wenn ich das obere zusammenfasse brauchen wir also eher eine Möglichkeit, die MAC-Adressen dynamisch zu setzen...

Da ist das Problem, dass sie im DHCP fest sind, also 00:01:12:13:01:00-00:01:12:13:02:ff für 32 IPs, aber wie willst du diese MACs den VMs zuweisen (Ohne Doppelte, etc...)?

@Dirk: Habe hier was gefunden:

Re: DHCP for specific range of mac addresses?

Originally Posted by Tom Horsley:
I'd like to run a dhcp server that will only respond to dhcp
requests from the virtual machines on my xen server box
(all of which use 00:16:3e as a mac address prefix).
...
Anyone know what "hardware" generates? Anyone have an example
of already doing something like this?

This works for me:
if binary-to-ascii (16, 8, "-", substring (hardware, 0, 4)) = "1-0-16-3e" {
max-lease-time 600;
}

"hardware" operator obviously generates binary garbage, which must be converted to ASCII before matching. In light of this we can also see that conditional expression binary-to-ascii (16, 32, "", substring (hardware, 0, 4)) = "100163e" should do the job as well.

See also log() statement in dhcp-eval manpage - it's useful for debugging - log (debug, binary-to-ascii (16, 8, "-", hardware));

Soetwas: Muss halt möglich sein, das auf eine Range abzubilden, so dass man mit 20 Adressen nur für diesen Zweck arbeiten könnte, ala virtuellen Pool.

Könnte im Zuge des Umsetzens des Stage1-Runlevel-Generierens angepasst werden (#211).