search for: conceipt

...certe solution. I think the key > for our discussion might be to define or refine the boundary between > VM and guest, e.g. what each layer is expected to control and manage > exactly. > > In my view, there might be possibly 3 different options to represent > the failover device conceipt to QEMU and libvirt (or any upper layer > software): > > a. Seperate device: in this model, virtio and passthough remains > separate devices just as today. QEMU exposes the standby feature bit > for virtio, and publish status/event around the negotiation process of > this feature...

...the key >> for our discussion might be to define or refine the boundary between >> VM and guest, e.g. what each layer is expected to control and manage >> exactly. >> >> In my view, there might be possibly 3 different options to represent >> the failover device conceipt to QEMU and libvirt (or any upper layer >> software): >> >> a. Seperate device: in this model, virtio and passthough remains >> separate devices just as today. QEMU exposes the standby feature bit >> for virtio, and publish status/event around the negotiation process o...

...to define or refine the boundary between >> >> VM and guest, e.g. what each layer is expected to control and manage >> >> exactly. >> >> >> >> In my view, there might be possibly 3 different options to represent >> >> the failover device conceipt to QEMU and libvirt (or any upper layer >> >> software): >> >> >> >> a. Seperate device: in this model, virtio and passthough remains >> >> separate devices just as today. QEMU exposes the standby feature bit >> >> for virtio, and publish...

...discussion might be to define or refine the boundary between > >> VM and guest, e.g. what each layer is expected to control and manage > >> exactly. > >> > >> In my view, there might be possibly 3 different options to represent > >> the failover device conceipt to QEMU and libvirt (or any upper layer > >> software): > >> > >> a. Seperate device: in this model, virtio and passthough remains > >> separate devices just as today. QEMU exposes the standby feature bit > >> for virtio, and publish status/event around...

I've been pointed to this discussion (which I had missed previously) and I'm getting a headache. Let me first summarize how I understand how this feature is supposed to work, then I'll respond to some individual points. The basic idea is to enable guests to migrate seamlessly, while still making it possible for them to use a passed-through device for more performance etc. The means to

...are tied to a specific or concerte solution. I think the key for our discussion might be to define or refine the boundary between VM and guest, e.g. what each layer is expected to control and manage exactly. In my view, there might be possibly 3 different options to represent the failover device conceipt to QEMU and libvirt (or any upper layer software): a. Seperate device: in this model, virtio and passthough remains separate devices just as today. QEMU exposes the standby feature bit for virtio, and publish status/event around the negotiation process of this feature bit for libvirt to react upon...