All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Josh Durgin <joshd@hq.newdream.net>
Cc: Sage Weil <sage@newdream.net>,
	libvir-list@redhat.com, ceph-devel@vger.kernel.org
Subject: Re: [libvirt] rbd storage pool support for libvirt
Date: Thu, 18 Nov 2010 10:42:14 +0000	[thread overview]
Message-ID: <20101118104214.GW15851@redhat.com> (raw)
In-Reply-To: <4CE47443.4000503@hq.newdream.net>

On Wed, Nov 17, 2010 at 04:33:07PM -0800, Josh Durgin wrote:
> Hi Daniel,
> 
> On 11/08/2010 05:16 AM, Daniel P. Berrange wrote:
> >>>>In any case, before someone goes off and implements something, does this
> >>>>look like the right general approach to adding rbd support to libvirt?
> >>>
> >>>I think this looks reasonable. I'd be inclined to get the storage pool
> >>>stuff working with the kernel RBD driver&  UDEV rules for stable path
> >>>names, since that avoids needing to make any changes to guest XML
> >>>format. Support for QEMU with the native librados CEPH driver could
> >>>be added as a second patch.
> >>
> >>Okay, that sounds reasonable.  Supporting the QEMU librados driver is
> >>definitely something we want to target, though, and seems to be route that
> >>more users are interested in.  Is defining the XML syntax for a guest VM
> >>something we can discuss now as well?
> >>
> >>(BTW this is biting NBD users too.  Presumably the guest VM XML should
> >>look similar?
> >
> >And also Sheepdog storage volumes. To define a syntax for all these we need
> >to determine what configuration metadata is required at a per-VM level for
> >each of them. Then try and decide how to represent that in the guest XML.
> >It looks like at a VM level we'd need a hostname, port number and a volume
> >name (or path).
> 
> It looks like that's what Sheepdog needs from the patch that was
> submitted earlier today. For RBD, we would want to allow multiple hosts,
> and specify the pool and image name when the QEMU librados driver is
> used, e.g.:
> 
>     <disk type="rbd" device="disk">
>       <driver name="qemu" type="raw" />
>       <source vdi="image_name" pool="pool_name">
>         <host name="mon1.example.org" port="6000">
>         <host name="mon2.example.org" port="6000">
>         <host name="mon3.example.org" port="6000">
>       </source>
>       <target dev="vda" bus="virtio" />
>     </disk>
> 
> Does this seem like a reasonable format for the VM XML? Any suggestions?

I'm basically wondering whether we should be going for separate types for
each of NBD, RBD & Sheepdog, as per your proposal & the sheepdog one earlier
today. Or type to merge them into one type 'nework' which covers any kind of
network block device, and list a protocol on the  source element, eg

     <disk type="network" device="disk">
       <driver name="qemu" type="raw" />
       <source protocol='rbd|sheepdog|nbd' name="...some image identifier...">
         <host name="mon1.example.org" port="6000">
         <host name="mon2.example.org" port="6000">
         <host name="mon3.example.org" port="6000">
       </source>
       <target dev="vda" bus="virtio" />
     </disk>


Regards,
Daniel
-- 
|: 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 :|

  parent reply	other threads:[~2010-11-18 10:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-02  3:52 rbd storage pool support for libvirt Sage Weil
2010-11-02 19:47 ` Wido den Hollander
2010-11-02 19:50   ` Wido den Hollander
2010-11-03 13:59 ` [libvirt] " Daniel P. Berrange
2010-11-05 23:33   ` Sage Weil
2010-11-08 13:16     ` Daniel P. Berrange
2010-11-18  0:33       ` Josh Durgin
2010-11-18  2:04         ` Josh Durgin
2010-11-18 10:38           ` Daniel P. Berrange
2010-11-18 10:42         ` Daniel P. Berrange [this message]
2010-11-18 17:13           ` Sage Weil
2010-11-19  9:27             ` Stefan Hajnoczi
2010-11-19  9:50               ` Daniel P. Berrange
2010-11-19 12:55                 ` Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101118104214.GW15851@redhat.com \
    --to=berrange@redhat.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=joshd@hq.newdream.net \
    --cc=libvir-list@redhat.com \
    --cc=sage@newdream.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.