Re: [libvirt] [PATCH] support sheepdog volumes
At Fri, 19 Nov 2010 14:56:35 -0800, Josh Durgin wrote: > > On 11/18/2010 04:42 PM, MORITA Kazutaka wrote: > > On 2010/11/18 19:46, Daniel P. Berrange wrote: > >> On Wed, Nov 17, 2010 at 06:19:58PM +0900, MORITA Kazutaka wrote: > >>> Sheepdog is a distributed storage system for QEMU. It provides highly > >>> available block level storage volumes to VMs like Amazon EBS. This > >>> patch adds support for Sheepdog; we can create VMs with sheepdog > >>> volumes, and attach sheepdog volumes to running machines via the > >>> attach-device command. > >>> > >>> Sheepdog volumes can be declared like this: > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> 'host' and 'port' in the source element are optional. If they are not > >>> specified, sheepdog clients use the default value (localhost:7000). > >> > >> I'm not too familiar with sheepdog implementation, but I understand > >> that each block device is stored across multiple hosts, but you're > >> only listing one hostname here. In the proposal for supporting RBD/ > >> CEPH in libvirt/QEMU, there's tan option to give multiple hostnames. > >> Is the need to give multiple hostnames going to be something that > >> is also relevant for Sheepdog, or does it cope with this in an > >> entirely different way ? > > > > We use the hostname as like a gateway to access sheepdog volumes. > > Though we could extend it to multiple hostnames to achieve high > > availability, how to use these parameters as qemu arguments needs to > > be discussed. > > For RBD, the monitor hostnames can be set through the environment. It > looks like this is easy to add to the libvirt QEMU driver. Would > environment variables work for sheepdog as well? No, but it looks much better to use environment variables for extending a sheepdog gateway to multiple servers. > > >> > >> As mentioned in the RBD thread[1], I'm wondering whether we should aim > >> for separate 'types' for each network block device or try to merge > >> them into one common syntax like > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > > > > Are monitor addresses necessary in the above syntax for RBD? I guess > > the monitor addresses are parameters to create a rbd image, but not > > ones to use a rbd image. If so, we can make the syntax a bit simpler like > > The monitors serve as gateways for RBD. All need to be specified > so that RBD can still access the cluster if some monitors go down. Sorry for confusion. If so, the first syntax Daniel suggested looks good for our storage volumes. Thanks, Kazutaka > > > > > > > > port="6000" /> > > > > > > > > > > Thannks, > > > > Kazutaka > > Thanks, > Josh > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] support sheepdog volumes
On 11/18/2010 04:42 PM, MORITA Kazutaka wrote: On 2010/11/18 19:46, Daniel P. Berrange wrote: On Wed, Nov 17, 2010 at 06:19:58PM +0900, MORITA Kazutaka wrote: Sheepdog is a distributed storage system for QEMU. It provides highly available block level storage volumes to VMs like Amazon EBS. This patch adds support for Sheepdog; we can create VMs with sheepdog volumes, and attach sheepdog volumes to running machines via the attach-device command. Sheepdog volumes can be declared like this: 'host' and 'port' in the source element are optional. If they are not specified, sheepdog clients use the default value (localhost:7000). I'm not too familiar with sheepdog implementation, but I understand that each block device is stored across multiple hosts, but you're only listing one hostname here. In the proposal for supporting RBD/ CEPH in libvirt/QEMU, there's tan option to give multiple hostnames. Is the need to give multiple hostnames going to be something that is also relevant for Sheepdog, or does it cope with this in an entirely different way ? We use the hostname as like a gateway to access sheepdog volumes. Though we could extend it to multiple hostnames to achieve high availability, how to use these parameters as qemu arguments needs to be discussed. For RBD, the monitor hostnames can be set through the environment. It looks like this is easy to add to the libvirt QEMU driver. Would environment variables work for sheepdog as well? As mentioned in the RBD thread[1], I'm wondering whether we should aim for separate 'types' for each network block device or try to merge them into one common syntax like Are monitor addresses necessary in the above syntax for RBD? I guess the monitor addresses are parameters to create a rbd image, but not ones to use a rbd image. If so, we can make the syntax a bit simpler like The monitors serve as gateways for RBD. All need to be specified so that RBD can still access the cluster if some monitors go down. Thannks, Kazutaka Thanks, Josh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] support sheepdog volumes
On 2010/11/18 19:46, Daniel P. Berrange wrote: > On Wed, Nov 17, 2010 at 06:19:58PM +0900, MORITA Kazutaka wrote: >> Sheepdog is a distributed storage system for QEMU. It provides highly >> available block level storage volumes to VMs like Amazon EBS. This >> patch adds support for Sheepdog; we can create VMs with sheepdog >> volumes, and attach sheepdog volumes to running machines via the >> attach-device command. >> >> Sheepdog volumes can be declared like this: >> >> >> >> >> >> >> >> 'host' and 'port' in the source element are optional. If they are not >> specified, sheepdog clients use the default value (localhost:7000). > > I'm not too familiar with sheepdog implementation, but I understand > that each block device is stored across multiple hosts, but you're > only listing one hostname here. In the proposal for supporting RBD/ > CEPH in libvirt/QEMU, there's tan option to give multiple hostnames. > Is the need to give multiple hostnames going to be something that > is also relevant for Sheepdog, or does it cope with this in an > entirely different way ? We use the hostname as like a gateway to access sheepdog volumes. Though we could extend it to multiple hostnames to achieve high availability, how to use these parameters as qemu arguments needs to be discussed. > > As mentioned in the RBD thread[1], I'm wondering whether we should aim > for separate 'types' for each network block device or try to merge > them into one common syntax like > > > > > > > > > > Are monitor addresses necessary in the above syntax for RBD? I guess the monitor addresses are parameters to create a rbd image, but not ones to use a rbd image. If so, we can make the syntax a bit simpler like Thannks, Kazutaka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] support sheepdog volumes
On Wed, Nov 17, 2010 at 06:19:58PM +0900, MORITA Kazutaka wrote: > Sheepdog is a distributed storage system for QEMU. It provides highly > available block level storage volumes to VMs like Amazon EBS. This > patch adds support for Sheepdog; we can create VMs with sheepdog > volumes, and attach sheepdog volumes to running machines via the > attach-device command. > > Sheepdog volumes can be declared like this: > > > > > > > > 'host' and 'port' in the source element are optional. If they are not > specified, sheepdog clients use the default value (localhost:7000). I'm not too familiar with sheepdog implementation, but I understand that each block device is stored across multiple hosts, but you're only listing one hostname here. In the proposal for supporting RBD/ CEPH in libvirt/QEMU, there's tan option to give multiple hostnames. Is the need to give multiple hostnames going to be something that is also relevant for Sheepdog, or does it cope with this in an entirely different way ? As mentioned in the RBD thread[1], I'm wondering whether we should aim for separate 'types' for each network block device or try to merge them into one common syntax like Regards, Daniel [1] http://www.redhat.com/archives/libvir-list/2010-November/msg00847.html -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] support sheepdog volumes
Sheepdog is a distributed storage system for QEMU. It provides highly
available block level storage volumes to VMs like Amazon EBS. This
patch adds support for Sheepdog; we can create VMs with sheepdog
volumes, and attach sheepdog volumes to running machines via the
attach-device command.
Sheepdog volumes can be declared like this:
'host' and 'port' in the source element are optional. If they are not
specified, sheepdog clients use the default value (localhost:7000).
Signed-off-by: MORITA Kazutaka
---
docs/schemas/domain.rng | 24 ++
src/conf/domain_conf.c | 26 ++-
src/conf/domain_conf.h |3 ++
src/qemu/qemu_conf.c| 63 +-
4 files changed, 113 insertions(+), 3 deletions(-)
diff --git a/docs/schemas/domain.rng b/docs/schemas/domain.rng
index bbbc846..5802993 100644
--- a/docs/schemas/domain.rng
+++ b/docs/schemas/domain.rng
@@ -612,6 +612,30 @@
+
+
+sheepdog
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 30c27db..d0ea0bb 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -113,7 +113,8 @@ VIR_ENUM_IMPL(virDomainDeviceAddress,
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_LAST,
VIR_ENUM_IMPL(virDomainDisk, VIR_DOMAIN_DISK_TYPE_LAST,
"block",
"file",
- "dir")
+ "dir",
+ "sheepdog")
VIR_ENUM_IMPL(virDomainDiskDevice, VIR_DOMAIN_DISK_DEVICE_LAST,
"disk",
@@ -505,6 +506,8 @@ void virDomainDiskDefFree(virDomainDiskDefPtr def)
VIR_FREE(def->serial);
VIR_FREE(def->src);
+VIR_FREE(def->host);
+VIR_FREE(def->port);
VIR_FREE(def->dst);
VIR_FREE(def->driverName);
VIR_FREE(def->driverType);
@@ -1517,6 +1520,8 @@ virDomainDiskDefParseXML(virCapsPtr caps,
char *driverName = NULL;
char *driverType = NULL;
char *source = NULL;
+char *host = NULL;
+char *port = NULL;
char *target = NULL;
char *bus = NULL;
char *cachetag = NULL;
@@ -1557,6 +1562,11 @@ virDomainDiskDefParseXML(virCapsPtr caps,
case VIR_DOMAIN_DISK_TYPE_DIR:
source = virXMLPropString(cur, "dir");
break;
+case VIR_DOMAIN_DISK_TYPE_SHEEPDOG:
+source = virXMLPropString(cur, "vdi");
+host = virXMLPropString(cur, "host");
+port = virXMLPropString(cur, "port");
+break;
default:
virDomainReportError(VIR_ERR_INTERNAL_ERROR,
_("unexpected disk type %s"),
@@ -1726,6 +1736,10 @@ virDomainDiskDefParseXML(virCapsPtr caps,
def->src = source;
source = NULL;
+def->host = host;
+host = NULL;
+def->port = port;
+port = NULL;
def->dst = target;
target = NULL;
def->driverName = driverName;
@@ -1756,6 +1770,8 @@ cleanup:
VIR_FREE(type);
VIR_FREE(target);
VIR_FREE(source);
+VIR_FREE(host);
+VIR_FREE(port);
VIR_FREE(device);
VIR_FREE(driverType);
VIR_FREE(driverName);
@@ -5831,6 +5847,14 @@ virDomainDiskDefFormat(virBufferPtr buf,
virBufferEscapeString(buf, " \n",
def->src);
break;
+case VIR_DOMAIN_DISK_TYPE_SHEEPDOG:
+virBufferEscapeString(buf, " src);
+if (def->host && def->port) {
+virBufferEscapeString(buf, " host='%s'", def->host);
+virBufferEscapeString(buf, " port='%s'", def->port);
+}
+virBufferVSprintf(buf, "/>\n");
+break;
default:
virDomainReportError(VIR_ERR_INTERNAL_ERROR,
_("unexpected disk type %s"),
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 7d2d6f5..9c929c4 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -120,6 +120,7 @@ enum virDomainDiskType {
VIR_DOMAIN_DISK_TYPE_BLOCK,
VIR_DOMAIN_DISK_TYPE_FILE,
VIR_DOMAIN_DISK_TYPE_DIR,
+VIR_DOMAIN_DISK_TYPE_SHEEPDOG,
VIR_DOMAIN_DISK_TYPE_LAST
};
@@ -172,6 +173,8 @@ struct _virDomainDiskDef {
int device;
int bus;
char *src;
+char *host;
+char *port;
char *dst;
char *driverName;
char *driverType;
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 83a117a..84f55cb 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -2731,6
