#359 added support for exporting guest time, importing it on the recipient side, tolerating skew between boot times across the source and destination systems, and wired it up into propolis-server. this stuff is all great, but in the mean time propolis-standalone got a fairly simple treatment of guest boot_hrtime.
I hadn't noticed this for a while, but this morning I kernel panicked my dev machine (me problem) and a VM I exported at ~60 days of uptime (this morning) now EINVALs on import because over in vmm_data_write_vmm_time we're rejecting src->vt_boot_hrtime > hrtime and will continue to for the next.. approximately sixty days.
I think just stuffing a VmTimeData into propolis-standalone's VmGlobalState would be basically fine on the export and import sides, but I haven't tested it and I'm chasing down something else at the moment...
#359 added support for exporting guest time, importing it on the recipient side, tolerating skew between boot times across the source and destination systems, and wired it up into propolis-server. this stuff is all great, but in the mean time
propolis-standalonegot a fairly simple treatment of guestboot_hrtime.I hadn't noticed this for a while, but this morning I kernel panicked my dev machine (me problem) and a VM I exported at ~60 days of uptime (this morning) now EINVALs on import because over in
vmm_data_write_vmm_timewe're rejectingsrc->vt_boot_hrtime > hrtimeand will continue to for the next.. approximately sixty days.I think just stuffing a
VmTimeDatainto propolis-standalone'sVmGlobalStatewould be basically fine on the export and import sides, but I haven't tested it and I'm chasing down something else at the moment...