pub struct Server {Show 30 fields
pub uuid: String,
pub title: String,
pub hostname: String,
pub plan: String,
pub zone: String,
pub state: String,
pub labels: Vec<Label>,
pub devices: Vec<Device>,
pub boot_order: BootOrder,
pub remote_access_enabled: bool,
pub remote_access_password: String,
pub vnc_port: u16,
pub reported_vnc_port: u16,
pub vnc_host: String,
pub reported_vnc_host: String,
pub public_ip: String,
pub utility_ip: String,
pub guest: Guest,
pub dhcp_client: DhcpClient,
pub ssh_host_key: String,
pub rtc: RtcInterpretation,
pub created_ms: u64,
pub transition: Option<Transition>,
pub ifaces: Vec<Iface>,
pub rules: Vec<Rule>,
pub firewall_on: bool,
pub metadata: bool,
pub timezone: String,
pub hotplug: bool,
pub console_settles_at: Option<u64>,
}Fields§
§uuid: String§title: String§hostname: String§plan: String§zone: String§state: String§labels: Vec<Label>§devices: Vec<Device>§boot_order: BootOrder§remote_access_enabled: bool§remote_access_password: String§vnc_port: u16What the hypervisor is really listening on.
reported_vnc_port: u16What the API SAYS it is listening on. These diverge on every stop/start
(behaviour 14) and only a remote_access_enabled no→yes toggle
reconciles them.
vnc_host: StringThe console is a HOST and a port, and the toggle re-provisions both.
MEASURED: after two PUTs the console came back as
se-sto1.vnc.upcloud.com:60031 — a ZONE host, not the server’s own
address. A client that re-reads only the port after the cure keeps
dialling the old place, which is the same defect one field further on.
reported_vnc_host: String§public_ip: String§utility_ip: String§guest: Guest§dhcp_client: DhcpClientWhat this guest’s DHCP client does with option 121. The provider
offers the routes; the guest does or does not install them. Same shape as
crate::guest_clock::RtcInterpretation, same reason.
ssh_host_key: StringA new one on every re-image. Which is expected, and which means every
automation that pushes to the forge meets
REMOTE HOST IDENTIFICATION HAS CHANGED on every bring-up.
rtc: RtcInterpretationHow THIS guest’s userland reads the RTC. The hypervisor presents
correct UTC to every server; the front gets it right and the appliance
does not, and the difference is the guest’s own software. Decided once,
at create, from Fault::GuestReadsRtcAsLocalTime — see
crate::guest_clock for why the clock itself is never skewed.
created_ms: u64§transition: Option<Transition>§ifaces: Vec<Iface>The interfaces this server was created with. See Iface.
rules: Vec<Rule>The rule SET on this machine. Empty is not the same as absent: an empty
set is a machine with the firewall ON and nothing allowed, and the API
answers [] for it exactly as it does for a machine nobody ever wrote
rules to. Only firewall tells the two apart.
firewall_on: boolfirewall: "on" | "off", as asked for at create.
metadata: boolmetadata: "yes" | "no", as asked for at create.
timezone: StringThe timezone the server was CREATED with, which is not the guest’s
wall clock. The detail renders this field because the provider reads
it back and a machine that asked for Europe/Stockholm and is answered
UTC is a permanent terraform diff. Behaviour 19 — the guest that reads
the RTC as local time — lives in crate::guest_clock and is untouched
by this: the API field says what was ASKED for, and the guest’s clock is
still wrong for its own reasons.
hotplug: boolBehaviour 60: can this guest’s kernel hot-plug PCI? Decided at
create from Fault::GuestKernelLacksHotplug; a property of the image.
console_settles_at: Option<u64>Behaviour 50: the console has not moved yet. Set by the “no” half of a toggle; a “yes” before the clock passes it gets the OLD endpoint back, which is why every working tool pauses between the two.
Implementations§
Source§impl Server
impl Server
Sourcepub fn clock_skew_ms(&self, unix_secs: i64) -> i64
pub fn clock_skew_ms(&self, unix_secs: i64) -> i64
What this guest’s wall clock reads, minus the truth, in ms. Zero for a guest whose userland knows the RTC is UTC.
Sourcepub fn dhcp_offer(&self) -> DhcpOffer
pub fn dhcp_offer(&self) -> DhcpOffer
The DHCP offer this server’s utility NIC received. Note it is the OFFER, which is always complete: what varies is whether the guest took it.