> Maybe my question is that whether the 'blocked' state is a primary state or > not, in the sense of virtual machine operation. I think we need to have > some abstraction here. How it is implemented is a different discussion.
Yes. > What I want say here is that we probably need 'different' level of > information, or a model of virtual machine operation. It seems to me that > the 'blocked' state is not a primary state. It is rather a kind of a > sub-state of primary states, or an attribute of primary states (e.g. a VM is > running (and blocked)). The key thing in any standard is that different folks read the standard and implement it. We then have a bakeoff/implementation report and see if we got it right nor not. I haven't put my two cents into the state machine yet either. And to me blocked given what is written so far is quite generic. Question is: what would an operator do if they saw a vm in blocked state? Here's some blocked states in VMware's implemtation. 1) Operator moved a vm fileset (vmx config file, vmdk virtual disks from a usb to a new machine and powered on. vmx process will block waiting for a connection to the vmx to answer the question (did you move or copy the vm?) It then updates the vmx config file appropriately. There are quite a number of "questions" that can block a VM. 2) VM can block operation during hot add/delete of devices, when doing live migration (vmotion (tm)) and so forth. Again is blocked something the operator has to deal with or not? Mike MacFaden Staff Engineer R&D Apps VMware, Inc Palo Alto CA _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
