LibVirt machinery should create the KVM domain #379
Conversation
|
What was the user-visible impact of not having the call in there? -Brad |
|
Cuckoo would hang eternally waiting for the VM to be started by an outside
actor. Guess not a lot of folks use KVM, which is odd since vbox won't run
with most grsec/pax protections.
Actually this hackery could use some exception handling around VM state,
but has been working fine so far.
…On Nov 26, 2016 8:15 AM, "Brad Spengler" ***@***.***> wrote:
What was the user-visible impact of not having the call in there?
-Brad
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#379 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABRPjCJUiwgbbdcHISAyeh-imcrMuRksks5rCDDpgaJpZM4K823w>
.
|
|
Is it libvirt version-specific? I've definitely used KVM extensively with cuckoo without any problems, and know of many others with the same experience. So I'd like to understand more about why we would need this change. -Brad |
|
My friends and I use kvm for long time with no errors/mods required also |
sempervictus
force-pushed
the
feature-modified-libvirt_start_create_domain
branch
from
bbd5020
to
697c7e4
Compare
Currently, LibVirt machinery can determine the snapshot and revert the VM state to it, but it jumps straight to waiting for a state change without actually issuing a create call to the domain being used. This is likely due to it expecting a live-state snapshot to be instantiated which automatically starts the instance. Add a conditional call self.vms[label].create() after resolving VM snapshot state and prior to entering the wait state. If the VM power state is still off, try to create the KVM domain with basic error handling. This should not case race conditions as preceeding snapshot operations are serialized and complete prior to returning.
sempervictus
force-pushed
the
feature-modified-libvirt_start_create_domain
branch
from
697c7e4
to
b2e26d6
Compare
|
I imagine most people probably take live-state snapshots and relying on libvirt to start the instance for them when instantiating one. I've been mostly using offline snaps since they dont register a relative boot time of prior to snapshot creation and just look like a freshly started host from the heuristic pespective. Along this train of thought, i've updated the PR to check VM power state after snapshot instantiation, and only attempt to create the domain if its still off under the premise that live snapshots would have turned it on already. Internal testing in live and offline snapshot use cases seems fine - hasn't blown up yet. |
|
How does cuckoo work if you don't take the snapshot with a running VM? |
|
@KillerInstinct - boot-time automation via cloud-init, Chef, etc. Simulates a freshly started machine opening a browser and downloading "bad stuff." |
|
Repo is dead |
|
Yeah, I know, was digging around for something else and ran across this thread again. Thanks for the heads up though. |
Currently, LibVirt machinery can determine the snapshot and revert
the VM state to it, but it jumps straight to waiting for a state
change without actually issuing a create call to the domain being
used.
Add a single line to call self.vms[label].create() after resolving
the snapshot state and prior to entering the wait state.