[Libvir] [Libvirt] Proposal to add 3 functions for VBDs (Virtual Block Devices)
After the new VCPU functions, we also need Virtual Block Device management equivalent to Xen commands: 'xm block-list', 'xm block-attach', 'xm block-detach'. I propose to add in Libvirt the following 3 functions: /** * virDomainGetVbdevs: * @domain: pointer to domain object, or NULL for Domain0 * @info: pointer to an array of virVbdevInfo structures * @maxinfo: number of structures in info array * * Extract information about virtual block devices of domain, store it in info. * * Returns the number of info filled in case of success, -1 in case of failure. */ int virDomainGetVbdevs(virDomainPtr domain, virVbdevInfoPtr info, int maxinfo) /** * virDomainCreateVbdev: * @domain: pointer to domain object, or NULL for Domain0 * @number: virtual device number * @mode: read-only (VIR_VBDMD_RO), or read/write (VIR_VBDMD_RW) * @bkendID: ID of domain hosting the backend device (usually 0 for domain0) * @bkend: pointer to backend device path * * Create a virtual block device. * * Returns 0 in case of success, -1 in case of failure. */ int virDomainCreateVbdev(virDomainPtr domain, unsigned int number, int mode, int bkendID, char *bkend) /** * virDomainDestroyVbdev: * @domain: pointer to domain object, or NULL for Domain0 * @number: virtual device number * * Destroy a virtual block device. * * Returns 0 in case of success, -1 in case of failure. */ int virDomainDestroyVbdev(virDomainPtr domain, unsigned int number) Structure in libvirt.h: /** * virVbdevInfo: information structure for a Virtual Block Device in a domain */ typedef struct _virVbdevInfo virVbdevInfo; struct _virVbdevInfo { unsigned int number; /* virtual device number */ int state; int evtChn; int ringRef; int bkendID; /* ID of domain hosting the backend device */ char bkend[128]; }; typedef virVbdevInfo *virVbdevInfoPtr; /* Virtual Block Device access modes: read-only or read/write */ #define VIR_VBDMD_RO 0 #define VIR_VBDMD_RW 1
On Thu, Aug 24, 2006 at 05:32:19PM +0200, michel.ponceau@bull.net wrote:
After the new VCPU functions, we also need Virtual Block Device management equivalent to Xen commands: 'xm block-list', 'xm block-attach', 'xm block-detach'. I propose to add in Libvirt the following 3 functions: /** * virDomainGetVbdevs: * @domain: pointer to domain object, or NULL for Domain0 * @info: pointer to an array of virVbdevInfo structures * @maxinfo: number of structures in info array * * Extract information about virtual block devices of domain, store it in info. * * Returns the number of info filled in case of success, -1 in case of failure. */ int virDomainGetVbdevs(virDomainPtr domain, virVbdevInfoPtr info, int maxinfo)
/** * virDomainCreateVbdev: * @domain: pointer to domain object, or NULL for Domain0 * @number: virtual device number * @mode: read-only (VIR_VBDMD_RO), or read/write (VIR_VBDMD_RW) * @bkendID: ID of domain hosting the backend device (usually 0 for domain0) * @bkend: pointer to backend device path * * Create a virtual block device. * * Returns 0 in case of success, -1 in case of failure. */ int virDomainCreateVbdev(virDomainPtr domain, unsigned int number, int mode, int bkendID, char *bkend)
/** * virDomainDestroyVbdev: * @domain: pointer to domain object, or NULL for Domain0 * @number: virtual device number * * Destroy a virtual block device. * * Returns 0 in case of success, -1 in case of failure. */ int virDomainDestroyVbdev(virDomainPtr domain, unsigned int number)
Humm, my concern here is how general is that API ? bkendID is certainly a Xen'ism, with no equivalent in other virtualization frameworks. If we add dynamic block devices creation and destruction, it must be clear what those operation means outside of a pure Xen context. In general devices are not named by one number, bkendID is a xen concept, I don't see why it should appear as is in the API.
Structure in libvirt.h: /** * virVbdevInfo: information structure for a Virtual Block Device in a domain */ typedef struct _virVbdevInfo virVbdevInfo; struct _virVbdevInfo { unsigned int number; /* virtual device number */ int state; int evtChn; int ringRef; int bkendID; /* ID of domain hosting the backend device */ char bkend[128]; }; typedef virVbdevInfo *virVbdevInfoPtr;
Way way too Xen specific, too undefined in general, as is this really cannot show up in libvirt API. I would prefer discussing the concept of the operation first instead of starting from a Xen standpoint and trying to make it an API. What are conceptually the operations you want to do ? How would you name the objects exposed in those oeprations ? Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
I think that, instead of designate the backend domain by its id, it would be better to designate it by its name. This is because the id isn't fix, excepted for the domain-0. Philippe Berthault. michel.ponceau@bull.net a écrit :
After the new VCPU functions, we also need Virtual Block Device management equivalent to Xen commands: 'xm block-list', 'xm block-attach', 'xm block-detach'. I propose to add in Libvirt the following 3 functions: /** * virDomainGetVbdevs: * @domain: pointer to domain object, or NULL for Domain0 * @info: pointer to an array of virVbdevInfo structures * @maxinfo: number of structures in info array * * Extract information about virtual block devices of domain, store it in info. * * Returns the number of info filled in case of success, -1 in case of failure. */ int virDomainGetVbdevs(virDomainPtr domain, virVbdevInfoPtr info, int maxinfo)
/** * virDomainCreateVbdev: * @domain: pointer to domain object, or NULL for Domain0 * @number: virtual device number * @mode: read-only (VIR_VBDMD_RO), or read/write (VIR_VBDMD_RW) * @bkendID: ID of domain hosting the backend device (usually 0 for domain0) * @bkend: pointer to backend device path * * Create a virtual block device. * * Returns 0 in case of success, -1 in case of failure. */ int virDomainCreateVbdev(virDomainPtr domain, unsigned int number, int mode, int bkendID, char *bkend)
/** * virDomainDestroyVbdev: * @domain: pointer to domain object, or NULL for Domain0 * @number: virtual device number * * Destroy a virtual block device. * * Returns 0 in case of success, -1 in case of failure. */ int virDomainDestroyVbdev(virDomainPtr domain, unsigned int number)
Structure in libvirt.h: /** * virVbdevInfo: information structure for a Virtual Block Device in a domain */ typedef struct _virVbdevInfo virVbdevInfo; struct _virVbdevInfo { unsigned int number; /* virtual device number */ int state; int evtChn; int ringRef; int bkendID; /* ID of domain hosting the backend device */ char bkend[128]; }; typedef virVbdevInfo *virVbdevInfoPtr;
/* Virtual Block Device access modes: read-only or read/write */ #define VIR_VBDMD_RO 0 #define VIR_VBDMD_RW 1 ------------------------------------------------------------------------
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Aug 24, 2006 at 05:54:21PM +0200, Philippe Berthault wrote:
I think that, instead of designate the backend domain by its id, it would be better to designate it by its name. This is because the id isn't fix, excepted for the domain-0.
Right, providing a flexible and generic enough naming scheme is probably the best, using strings is definitely better IMHO. Usually devices will be associated to existing devices or files, which will be referenced by names. If those resources doesn't exist as such or can't be named, it's better to still build a naming scheme around the mechanism, for example: 'xen:vbd:0:1234' or 'xen:vif:2:0123' and using those names separates the API from the specifics, while allowing some flexibility. And it may be better to think in term of 'device' than 'block device' at that level, I don't see why we should do the same game again in 2 months once one realize that one also want to address for example network cards. Using string constructs for names keeps the API more generic, more flexible but one will need to explain in the documentation what names are accepted, and what the constructs means. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Thu, Aug 24, 2006 at 12:51:58PM -0400, Daniel Veillard wrote:
On Thu, Aug 24, 2006 at 05:54:21PM +0200, Philippe Berthault wrote:
I think that, instead of designate the backend domain by its id, it would be better to designate it by its name. This is because the id isn't fix, excepted for the domain-0.
Right, providing a flexible and generic enough naming scheme is probably the best, using strings is definitely better IMHO. Usually devices will be associated to existing devices or files, which will be referenced by names. If those resources doesn't exist as such or can't be named, it's better to still build a naming scheme around the mechanism, for example:
'xen:vbd:0:1234' or 'xen:vif:2:0123'
and using those names separates the API from the specifics, while allowing some flexibility.
This is just exposing xen specific attributes via the backdoor, rather than via an explicit API. The result is same - applications will become more dependant on particular hypervisor impementation details. If we're going to expose block info & allow attach / detach, we should follow the data format already exposed for block devices in the XML: - device name - eg hda, xvda1, xvda1, etc - backing store - path to a file - type - phys / file - readonly - boolean - type - floppy, cdrom, disk Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Thu, Aug 24, 2006 at 05:58:02PM +0100, Daniel P. Berrange wrote:
On Thu, Aug 24, 2006 at 12:51:58PM -0400, Daniel Veillard wrote:
On Thu, Aug 24, 2006 at 05:54:21PM +0200, Philippe Berthault wrote:
I think that, instead of designate the backend domain by its id, it would be better to designate it by its name. This is because the id isn't fix, excepted for the domain-0.
Right, providing a flexible and generic enough naming scheme is probably the best, using strings is definitely better IMHO. Usually devices will be associated to existing devices or files, which will be referenced by names. If those resources doesn't exist as such or can't be named, it's better to still build a naming scheme around the mechanism, for example:
'xen:vbd:0:1234' or 'xen:vif:2:0123'
and using those names separates the API from the specifics, while allowing some flexibility.
This is just exposing xen specific attributes via the backdoor, rather than via an explicit API. The result is same - applications will become more dependant on particular hypervisor impementation details.
well I wanted just to illustrate the case where we can't name the resources in a preexisting way. I was thinking of the specifc case were you ask domain n to map a device exported from domain m.
If we're going to expose block info & allow attach / detach, we should follow the data format already exposed for block devices in the XML:
- device name - eg hda, xvda1, xvda1, etc - backing store - path to a file - type - phys / file - readonly - boolean - type - floppy, cdrom, disk
In the general case, yes we need to reuse those existing names, just that we may need to invent more names. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
michel.ponceau＠bull.net -
Philippe Berthault