Hello, On 2013/08/30, at 14:02, Michael MacFaden <[email protected]> wrote:
> 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. Thank you for showing some examples in VMware. Since I'm not very familiar with it, the above information is quite useful to me. And, the above examples are cases what I was not thinking about. They are events caused by procedures of virtual machine 'operation'. I tend to agree that the VirtualMachineOperState should be able to distinguish the above situations… I still think the above situations and the blocked state of Xen (caused by I/O wait between DomU and Dom0, which is not cased by operator's actions) are a bit different context. In the current VMM-MIB draft though, both situations are marked as blocked. But I'm not sure it is a correct design or not. I noticed that I have one assumption that we haven't shared among us. In my understanding, the state transition is initiated by operation actions (except the crash case). So, the transition to/from the blocked state looks a bit strange to me. But Juergen doesn't have such an assumption. That is the reason of the gap between I and others, maybe. > 2) VM can block operation during hot add/delete of devices, when doing > live migration (vmotion (tm)) and so forth. This case is also a confusing case to me. In the current draft, when a VM is migrated, its state is changed to the 'migrating' state. But in the VMware case, the state is blocked (or migrating & blocked, maybe). It may be necessary to review and refine the meanings of VirtualMachineOperState and the model of the state machine more carefully. Though I'm not sure if it must be done in the current version. Or maybe in the next major revision based on inputs from implementors and operators. Regards, --- Keiichi SHIMA (島 慶一) WIDE project <[email protected]> Research Laboratory, IIJ Innovation Institute, Inc <[email protected]> On 2013/08/30, at 14:02, Michael MacFaden <[email protected]> wrote: >> 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 _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
