On 2020-10-01 2:29 a.m., wferi@xxxxxxx wrote: > daggs <daggs@xxxxxxx> writes: > >> I'd assume that saying vm running you mean that the os is up and >> running too. I have similar need, I was able to get something as such >> to work using virsh console when the guest was a linux with serial >> console support enabled. I wasn't able to get this to work in a >> script as I was never able to terminate the console seesion as virsh >> console wasn't able to send the termination combination properly. > > I wouldn't have assumed this meaning, but running off the tangent > anyway: I think installing a guest agent could help solving this > problem. However, if you want something extremely lightweight, the > following (a custom one-line guest agent if you wish) worked for me: > > 1. Add a channel with a descriptive name to the guest config: > > <channel type="unix"> > <target type="virtio" name="startup_signal"/> > </channel> > > 2. After starting the domain, query the assigned socket path: > > virsh dumpxml $domain | xmllint --nonet --xpath \ > "string(/domain/devices/channel[@type='unix' and target/@name='startup_signal']/source/@path)" -) > > 3. Then wait for the signal (and optionally acknowledge it): > > socat UNIX-CONNECT:"$socket_path" \ > SYSTEM:'read msg id && [ $msg = ready ] && echo ack $id' > > This will wait until you send the signal from the chosen point of the > guest bootup procedure via something like: > > port=/dev/virtio-ports/startup_signal > msg=foobar > reply="$(echo "ready $msg" | socat STDIO "$port")" > [ "($reply)" = "(ack $msg)" ] # for checking proper acknowledgment > > I folded this into a oneshot systemd service on Linux, but the > implementation should be similarly simple under any OS. Thanks, both. In our case, we have zero control over the servers installed in our platform, and asking users to install agents in their OSes is not feasible. I did find a way to do it working around virsh, but of course I'd prefer to directly query the source instead of infering it if possible. The work around we're doing now is watching for a given guest to transition from 'shut off' to 'running' and, when that transition is seen, using the guest's PID to query 'ps -p <pid> -o etimes=' and subtracting the current epoch time minus the returned value to get the boot time. When the server transitions to 'shut off', we reset the stored boot time to 0. -- Digimer Papers and Projects: https://alteeve.com/w/ "I am, somehow, less interested in the weight and convolutions of Einstein’s brain than in the near certainty that people of equal talent have lived and died in cotton fields and sweatshops." - Stephen Jay Gould
