[libvirt] using sync_manager with libvirt

[Itamar Heim]

> From: libvir-list-bounces at redhat.com [mailto:libvir-list-
> bounces at redhat.com] On Behalf Of Daniel P. Berrange
...
> > A command would be something like this:
> >
> > sync_manager daemon -i <host_id> -n <vm_id> -l <lease> -c <command>
> <args>
> >
> >   <host_id>	is integer between 1 and 2000 that is statically
> > 		assigned to each host.
> >
> >   <vm_id>	is a unique identifer for the process that will be run,
> > 		e.g. the vm name or uuid.
> >
> >   <lease>	defines the shared storage area that sync_manager should
> > 		use for performing the disk-paxos based synchronization.
> > 		It consists of <resource_name>:<path>:<offset>, where
> > 		<resource_name> is likely to be the vm name/uuid (or the
> > 		name of the vm's disk image), and <path>:<offset> is an
> > 		area of shared storage that has been allocated for
> > 		sync_manager to use (a separate area for each
resource/vm).
> 
> Can you give some real examples of the lease arg ?  I guess <path> must
> exclude the ':' character, or have some defined escaping scheme.
> 
> >
> >   <command> <args>
> > 		would be the qemu command line that is currently used.
> >
> > We expect these new config values will need a place to live in the
> libvirt
> > xml config file, and libvirt will need to fork sync_manager -c qemu
> rather
> > than qemu directly.  At least those are the most obvious things that
> need
> > doing, there are sure to be other api or functional issues.
> 
> The <host_id> is obviously needs to be in /etc/libvirt/sync-manager.conf
> since that's a per-host config. I assume the shared storage area is per
> host too ?
> 
> That leaves just the VM name/uuid as a per-VM config option, and we
> obviously already have that in XML.  Is there actually any extra
> attribute we need to track per-guest in the XML ? If not this will
> simplify life, because we won't have to track sync-manager specific
> attributes
[IH] the shared storage is per shared storage domain the host accesses,
which can be multiple / change during host lifetime, so easiest as a
parameter.
Actually, same goes to host id - since the host id can (and will) be
different for each storage domain.
(if hosts A,B,C are using shared storage S1, their ID's are probably
1,2,3. If B,C,D are sharing storage S2, they are probably 1,2,3 for that
storage domain).
The important thing is the host id is unique for all hosts per storage
lease area, it's not really per host.