Hi Morita (is this your first name ?), > > 1. is it possible to use sheepdog as storage for resuming/suspending > > KVM machines ? Normaly, kvm invokes a command like dd or cat to > > store/restore the RAM to/from disk ... this may will not work > > with sheepdog in the current version, or ? > > Not supported yet, but it will be supported in future. > To support resuming/suspending, sheepdog need to support online > snapshot. It is included in our TODO list. So, i currently cannot take a "normal"-KVM snapshot to a normal filesystem (e.g. ext3) using the normale KVM-snapshot approach ? Or do you mean, it's not possible to store these snapshots directly on the sheepdog-servers. May it's (later) possible to 1) create a sheepdog volume manually 2) start kvm-tools manually to store the suspend-data using to the volume ? Ok ... there's no sheepdog standalone-client to store data to the volume. KVM uses dd/cat to store data - but these commands cannot be used to access your volume... 3) resume the vm using kvm-tools manually (some problem - no standalone sheepdog client) 4) delete the sheepdog-volume manually > > > 2. to be sure - the KVM machines could run on a sheepdog server member, > > but can also run on not-sheepdog-server machine connecting > > to the sheepdog cluster via IP and multicast. > > It may be possible to support vm runs outside sheepdog servers. > We currently assume virtual machines run on sheepdog server machines > to enable zero-hop data accessing and to check vm is alive. > We can think of removing this restriction if it is needed. In "big" (e.g. >10 KVM server) environment, the KVM-server boots via PXE+diskless-NFS (we do ..) and has no or only a small local HDD (using e.g. redhat satellite-server). This will reduce overhead of keeping the servers in sync. Therefore, it make no sense to add big local storage to the systems. It would be great, if you can add this issue "kvm-server must not be a sheepdog-storage server" to your TODO-list (-: best regards Danny |