Re: [Openstack] OpenStack Folsom (Devstack) Network Pre-configuration

[Marton Kiss]

Hey Yuping,

You could check this page, it could be related to your question:
https://answers.launchpad.net/quantum/+question/208377

Regards,
  Márton Kiss


2013/1/18 Rain Lee 

> Hi all,
>
> I am using devstack to deploy an experiment cloud, following exactly
> everything as listed on http://devstack.org. I want to try the devstack
> all-in-one options upon a Ubuntu-desktop 12.10 host directly. After
> shooting the stack.sh script, everything seems to work as expected, I can
> successfully launch a fresh instance from horizon interface, but I can't
> access (ping) the instance from my host machine.
>
> I have two NICs, eth0 is statically configured with 192.168.1.100, eth1 is
> configured in promiscuous mode. I can reach Internet from eth0 and with
> command "brctl show", I can confirm eth1, vnet0 are plugged in the br100
> bridge.
>
> Digging around, I found in the DHCP release, DHCPOFFER, no DHCPREQUEST,
> DHCPACK in /var/log/syslog. And with tcpdump, I can get ARP request packets
> on interface br100 and vnet0, but nothing on eth1.
>
> Since it's all-in-one mode, there seems no other traffic between different
> nodes, so I just leave eth1 unplugged in any switch/routers, is this the
> problem? Or can i just use one NIC to set up the environment, then how? Can
> anyone please further clarify the network pre-configuration requirements
> for openstack, for single node and multi-nodes? Thanks.
>
> Regards,
> Yuping
>
>
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] [Openstack-dev]Where is libvirt library packages in Openstack Nova branch

[harryxiyou]

Hi all,

I read the source code of Openstack Nova branch source codes but i
can not find the  standard libvirt library packages, which i think
Nova uses libvirt
interfaces they are from standard libvirt library to attach Sheepdog(or others)
volumes to QEMU. If i add a new block storage driver for standard libvirt,
i have to update these libvirt library packages in Openstack Nova brahch.
Cloud anyone give me some suggestions? Thanks in advance ;-)

-- 
Thanks
Harry Wei

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [Openstack-dev][Sheepdog]Add a new driver for Openstack Cinder like Sheepdog volumes

[harryxiyou]

On Sat, Jan 19, 2013 at 10:09 PM, Huang Zhiteng  wrote:
> It seems you also have tgt patch for HLFS, personally I'd prefer iSCSI
> support over qEMU support since iSCSI is well supported by almost every
> hypervisor.
>
We will first realize HLFS driver by Qemu/Libvirt way for Openstack. Then,
we will also realize iSCSI way. Thanks for your suggestions ;-)

-- 
Thanks
Harry Wei

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [Sheepdog][Libvirt][Qemu]Add a new block storage driver by Libvirt/Qemu way for Openstack

[harryxiyou]

On Sat, Jan 19, 2013 at 10:04 PM, MORITA Kazutaka
 wrote:
> At Sat, 19 Jan 2013 16:47:37 +0800,
[...]
> If you do the above work, I think you can use your file system with
> OpenStack.
>

Thanks for your review ;-)

> But I suggest doing them step by step.  If your file system is not
> supported in QEMU, I think libvirt won't support it.  If libvirt
> doesn't support it, OpenStack shouldn't support it too.
>

Yes, i think so. I will finish this job step by step ;-)



-- 
Thanks
Harry Wei

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [Openstack-dev][Sheepdog]Add a new driver for Openstack Cinder like Sheepdog volumes

[Huang Zhiteng]

It seems you also have tgt patch for HLFS, personally I'd prefer iSCSI
support over qEMU support since iSCSI is well supported by almost every
hypervisor.
On Jan 19, 2013 9:23 PM, "harryxiyou"  wrote:

> On Sat, Jan 19, 2013 at 7:00 PM, Huang Zhiteng 
> wrote:
> > Until the QEMU support is official, I don't think it's a good idea
> >to have HLFS driver in Cinder.
> >
>
> It sounds reasonable, we will send our patches to QEMU&&Libvirt
> community. After the patches are merged, we will send patch to
> Openstack. Do you have any other suggestions?
>
>
> --
> Thanks
> Harry Wei
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [Sheepdog][Libvirt][Qemu]Add a new block storage driver by Libvirt/Qemu way for Openstack

[MORITA Kazutaka]

At Sat, 19 Jan 2013 16:47:37 +0800,
harryxiyou wrote:
> 
> Hi all,
> 
> I wanna add a new block storage driver by Libvirt/Qemu way for Openstack, 
> which
> is as same as Sheepdog driver for Openstack. So i think the theories
> are like this.
> 
> 1, In the Openstack Nova branch, Openstck driver call libvirt client
> and send parameters
> to libvirt client.(From this point, i should modify Openstack Nova
> source codes. They are
> a, nova/nova/virt/libvirt/driver.pyadd new driver way
> b, /OpenStack/nova/nova/tests/test_libvirt.py  add new driver test)
> 
> 2, According to own protocol, libvirt client in Openstack Nova branch
> send parameters to
> Libvirt server.(From this point, i should modify libvirt library to
> let libvirt library support this
> new driver like Sheepdog).
> 
> 3, Libvirt server call Qemu interfaces to send parameters to
> Qemu.(From this point, i should
> modify Qemu source codes to let Qemu support this new driver like Sheepdog).
> 
> 4, In Openstack Cinder branch, Openstack driver use Qemu commands to
> create this new volumes
> to Qemu.(From this point, i should modify Openstack Cinder branch
> source codes like this.
> a, Add new driver file
> /OpenStack/cinder/cinder/volume/drivers/new_driver.py like Sheepdog.py
> b, Change file /OpenStack/cinder/cinder/tests/test_drivers_compatibility.py
> to test new driver).
> 
> 5, At last, i should also modify
> /OpenStack/manuals/doc/src/docbkx/openstack-compute-admin/tables/hypervisors-nova-conf.xml
> to configure this new driver.
> 
> Are my theories right? Should i do any other stuffs? Could anyone give
> me any other suggestions?

If you do the above work, I think you can use your file system with
OpenStack.

But I suggest doing them step by step.  If your file system is not
supported in QEMU, I think libvirt won't support it.  If libvirt
doesn't support it, OpenStack shouldn't support it too.

Thanks,

Kazutaka

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [Openstack-dev][Sheepdog]Add a new driver for Openstack Cinder like Sheepdog volumes

[harryxiyou]

On Sat, Jan 19, 2013 at 7:00 PM, Huang Zhiteng  wrote:
> Until the QEMU support is official, I don't think it's a good idea
>to have HLFS driver in Cinder.
>

It sounds reasonable, we will send our patches to QEMU&&Libvirt
community. After the patches are merged, we will send patch to
Openstack. Do you have any other suggestions?


-- 
Thanks
Harry Wei

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Network setup - Swift / keystone location and configuraton?

[Brian Ipsen]

Hi

As for the network diagram the one on the referred page 
(http://docs.openstack.org/trunk/openstack-object-storage/admin/content/figures/swift_install_arch.png)
 more or less looks what I plan on doing. I would just put a NAT'ing firewall 
between the public switch and the internet. For security reasons, I think it 
would make more sense to have the Auth node (keystone service) located on the 
private switch - but I am not sure whether it is possible.

I am still trying to figure out how the different components interact, and 
exactly what the different parameters on the keystone command does. Once I get 
that understanding, things will probably be much easier :)

Regarding the location of the keystone server - and please correct me, if I'm 
wrong; user authentication is done via the proxy. When a user authenticates, I 
assume that the proxy asks the keystone/auth server - instead of the client 
asks the auth/keystone server directly? If it is the proxy that handles the 
authentication request towards the keystone server - then the keystone might as 
well be located on the private switch on the drawing (for enhanced security). 
Of course, if the keystone service is located on the private switch, the IP 
addresses in the URL's for the endpoint creation will need to match the IP 
address of the server in this network.

Clients will be located on the internet side on the drawing (again - I want to 
put a NAT'ing firewall between the public switch and what is referred to as 
"internet" on the drawing).

Maybe I should start digging into the book "OpenStack Cloud Computing Cookbook" 
by Kevin Jackson to see if this can make things clearer for me :)

Regards
Brian


From: Kuo Hugo [mailto:tonyt...@gmail.com]
Sent: 19. januar 2013 09:58
To: Brian Ipsen
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Network setup - Swift / keystone location and 
configuraton?

The answer is depends on your service plan .

Generally , the IP for keystone is the network which could be accessed from 
client .
Also , the publicurl / adminurl / internal could be different .

Keystone is the auth agent for swift(and all other services) , while you 
produce a request to ask for "services URLs / role / token" with your 
username/password . It will return a bunch of of information .
In keystone v1.0 legacy auth method , it presents as several x-headers .
In keystone v2.0 , it returns a pack of json which includes more information . 
Such as service urls , in your case the service type is object-storage(aka. 
swift) .

The client could parse the needed url for using.
The swift-client is using --publicurl as I know .

[Q]Could I have a question ?
Which network will the client located ?

For x.x.x.x , you can just fill in the IP which accessible from client . If 
there's a NAT of LB , you need to point to NAT entry point of LB IP and 
redirect to the service port or internal IP .

keystone endpoint-create --region RegionOne --service-id $KEYSVC_ID --publicurl 
'http://x.x.x.x5000/v2.0' --adminurl 'http://x.x.x.x:35357/v2.0' --internalurl 
'http://x.x.x.x:5000/v2.0'
keystone endpoint-create --service-id $SWIFTSVC_ID --publicurl 
'http://x.x.x.x:8080/v1/AUTH_\$(tenant_id)s'
 --adminurl 
'http://x.x.x.x:8080/v1/AUTH_\$(tenant_id)s
 ' --internalurl ' 
http://x.x.x.x:8080/v1/AUTH_\$(tenant_id)s
 '

2013/1/19 Brian Ipsen 
mailto:brian.ip...@ryesgade47c.dk>>
Hi

I am trying to figure out how to build a swift setup with Keystone identity 
management - and have the environment secured by a firewall.

I expect, that a number of proxy nodes are accessible through the firewall 
(traffic will be NAT'ed). The proxy nodes are connected to a private "storage 
network" (not accessible from the outside) on a second network interface. Will 
the keystone have to be on the "public" side of the proxy nodes - or can it be 
on the "private" side (see 
http://docs.openstack.org/trunk/openstack-object-storage/admin/content/example-object-storage-installation-architecture.html
 - here it is on the "public" side)

But I am not quite sure about the configuration of the different service when 
it comes to specifying the different URL's...
For example, for the Keystone service:

Assuming, that storage/swift nodes are located in the range 
172.21.100.20-172.21.100.80, the keystone server on 172.21.100.10 - and the 
proxies on 172.21.100.100-172.21.100.120 (and external 
10.32.30.10-10.32.30.30). What would be the correct IP's to use on this command 
?
keystone service-create --name keystone --type=identity --description "Keystone 
Identity Service"
keystone endpoint-create --region RegionOne --service-id $KEYSVC_ID --publicurl 
'http://x.x.x.x5000/v2.0' --adminurl 'http://x.x.x.x:35357/v2.0' --internalurl 
'http://x.x.x.x:5000/v2.0'

And for swift:
keystone service-create --name keystone --type=identity --description "Swif

Re: [Openstack] [Openstack-dev][Sheepdog]Add a new driver for Openstack Cinder like Sheepdog volumes

[Huang Zhiteng]

Until the QEMU support is official, I don't think it's a good idea to
have HLFS driver in Cinder.

On Sat, Jan 19, 2013 at 1:14 PM, harryxiyou  wrote:
> On Sat, Jan 19, 2013 at 12:24 PM, MORITA Kazutaka
>  wrote:
>> At Fri, 18 Jan 2013 22:56:38 +0800,
> [...]
>>
>> The answer depends on the protocol between QEMU and HLFS.  What is
>> used for accessing HLFS volumes from QEMU?  Is it iSCSI, NFS, or
>> something else?
>>
>
> Actually, we just realize the block driver interfaces QEMU provided.
> You can see our
> patch from
> http://code.google.com/p/cloudxy/source/browse/trunk/hlfs/patches/hlfs_driver_for_qemu.patch
>
> And what about Sheepdog? What is used for accessing Sheepdog volumes from 
> QEMU?
> Is it iSCSI, NFS, or something else?
>
> --
> Thanks
> Harry Wei
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp



-- 
Regards
Huang Zhiteng

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [Openstack-dev][Sheepdog]Add a new driver for Openstack Cinder like Sheepdog volumes

[harryxiyou]

On Sat, Jan 19, 2013 at 5:27 PM, MORITA Kazutaka
 wrote:
> At Sat, 19 Jan 2013 13:14:42 +0800,
> harryxiyou wrote:
[...]
>
> Sheepdog uses an own protocol, and I think your file system is similar.
>
> IIUC, what you need to do are:
>  1. modify libvirt so that you can specify your file system as a QEMU
> disk
>  2. add a volume driver to Cinder to handle your file system
>
> You don't need to modify Nova.  You can use
> nova.virt.libvirt.volume.LibvirtNetVolumeDriver as a libvirt volume
> driver like sheepdog and rbd.
>

I have the same thoughts. Morita, thanks for your help.
You can also see another emali i sent to you a moment ago named
"Add a new block storage driver by Libvirt/Qemu way for Openstack",
which says how to add a new block storage for Openstack in details.
I hope you can review that one and give me your suggestions if you
have free time. Thanks in advance ;-)

-- 
Thanks
Harry Wei

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [Openstack-dev][Sheepdog]Add a new driver for Openstack Cinder like Sheepdog volumes

[MORITA Kazutaka]

At Sat, 19 Jan 2013 13:14:42 +0800,
harryxiyou wrote:
> 
> On Sat, Jan 19, 2013 at 12:24 PM, MORITA Kazutaka
>  wrote:
> > At Fri, 18 Jan 2013 22:56:38 +0800,
> [...]
> >
> > The answer depends on the protocol between QEMU and HLFS.  What is
> > used for accessing HLFS volumes from QEMU?  Is it iSCSI, NFS, or
> > something else?
> >
> 
> Actually, we just realize the block driver interfaces QEMU provided.
> You can see our
> patch from
> http://code.google.com/p/cloudxy/source/browse/trunk/hlfs/patches/hlfs_driver_for_qemu.patch
> 
> And what about Sheepdog? What is used for accessing Sheepdog volumes from 
> QEMU?
> Is it iSCSI, NFS, or something else?

Sheepdog uses an own protocol, and I think your file system is similar.

IIUC, what you need to do are:
 1. modify libvirt so that you can specify your file system as a QEMU
disk
 2. add a volume driver to Cinder to handle your file system

You don't need to modify Nova.  You can use
nova.virt.libvirt.volume.LibvirtNetVolumeDriver as a libvirt volume
driver like sheepdog and rbd.

Thanks,

Kazutaka

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Network setup - Swift / keystone location and configuraton?

[Kuo Hugo]

Would you mind to have a network diagram of your environment ?

Hugo


2013/1/19 Brian Ipsen 

>  Hi
>
> ** **
>
> I am trying to figure out how to build a swift setup with Keystone
> identity management – and have the environment secured by a firewall.
>
> ** **
>
> I expect, that a number of proxy nodes are accessible through the firewall
> (traffic will be NAT’ed). The proxy nodes are connected to a private
> “storage network” (not accessible from the outside) on a second network
> interface. Will the keystone have to be on the “public” side of the proxy
> nodes – or can it be on the “private” side (see
> http://docs.openstack.org/trunk/openstack-object-storage/admin/content/example-object-storage-installation-architecture.html-
>  here it is on the “public” side)
> 
>
> ** **
>
> But I am not quite sure about the configuration of the different service
> when it comes to specifying the different URL’s…
>
> For example, for the Keystone service:
>
> ** **
>
> Assuming, that storage/swift nodes are located in the range
> 172.21.100.20-172.21.100.80, the keystone server on 172.21.100.10 – and the
> proxies on 172.21.100.100-172.21.100.120 (and external
> 10.32.30.10-10.32.30.30). What would be the correct IP’s to use on this
> command ?
>
> keystone service-create --name keystone --type=identity --description
> "Keystone Identity Service"
>
> keystone endpoint-create --region RegionOne --service-id $KEYSVC_ID
> --publicurl 'http://x.x.x.x5000/v2.0' --adminurl '
> http://x.x.x.x:35357/v2.0' --internalurl 'http://x.x.x.x:5000/v2.0'
>
> ** **
>
> And for swift:
>
> keystone service-create --name keystone --type=identity --description
> "Swift Storage Service"
>
> keystone endpoint-create --service-id $SWIFTSVC_ID --publicurl '
> http://x.x.x.x:8080/v1/AUTH_\$(tenant_id)s' --adminurl '
> http://x.x.x.x:8080/v1/AUTH_\$(tenant_id)s ' --internalurl '
> http://x.x.x.x:8080/v1/AUTH_\$(tenant_id)s '
>
> ** **
>
> Regards
>
> Brian
>
> ** **
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
+Hugo Kuo+
tonyt...@gmail.com
+ 886 935004793
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Network setup - Swift / keystone location and configuraton?

[Kuo Hugo]

The answer is depends on your service plan .

Generally , the IP for keystone is the network which could be accessed from
client .
Also , the publicurl / adminurl / internal could be different .

Keystone is the auth agent for swift(and all other services) , while you
produce a request to ask for "services URLs / role / token" with your
username/password . It will return a bunch of of information .
In keystone v1.0 legacy auth method , it presents as several x-headers .
In keystone v2.0 , it returns a pack of json which includes more
information . Such as service urls , in your case the service type is
object-storage(aka. swift) .

The client could parse the needed url for using.
The swift-client is using --publicurl as I know .

[Q]Could I have a question ?

Which network will the client located ?


For x.x.x.x , you can just fill in the IP which accessible from client . If
there's a NAT of LB , you need to point to NAT entry point of LB IP and
redirect to the service port or internal IP .

keystone endpoint-create --region RegionOne --service-id $KEYSVC_ID
--publicurl 'http://x.x.x.x5000/v2.0' --adminurl 'http://x.x.x.x:35357/v2.0'
--internalurl 'http://x.x.x.x:5000/v2.0'
keystone endpoint-create --service-id $SWIFTSVC_ID --publicurl '
http://x.x.x.x:8080/v1/AUTH_\$(tenant_id)s' --adminurl '
http://x.x.x.x:8080/v1/AUTH_\$(tenant_id)s ' --internalurl '
http://x.x.x.x:8080/v1/AUTH_\$(tenant_id)s '


2013/1/19 Brian Ipsen 

>  Hi
>
> ** **
>
> I am trying to figure out how to build a swift setup with Keystone
> identity management – and have the environment secured by a firewall.
>
> ** **
>
> I expect, that a number of proxy nodes are accessible through the firewall
> (traffic will be NAT’ed). The proxy nodes are connected to a private
> “storage network” (not accessible from the outside) on a second network
> interface. Will the keystone have to be on the “public” side of the proxy
> nodes – or can it be on the “private” side (see
> http://docs.openstack.org/trunk/openstack-object-storage/admin/content/example-object-storage-installation-architecture.html-
>  here it is on the “public” side)
> 
>
> ** **
>
> But I am not quite sure about the configuration of the different service
> when it comes to specifying the different URL’s…
>
> For example, for the Keystone service:
>
> ** **
>
> Assuming, that storage/swift nodes are located in the range
> 172.21.100.20-172.21.100.80, the keystone server on 172.21.100.10 – and the
> proxies on 172.21.100.100-172.21.100.120 (and external
> 10.32.30.10-10.32.30.30). What would be the correct IP’s to use on this
> command ?
>
> keystone service-create --name keystone --type=identity --description
> "Keystone Identity Service"
>
> keystone endpoint-create --region RegionOne --service-id $KEYSVC_ID
> --publicurl 'http://x.x.x.x5000/v2.0' --adminurl '
> http://x.x.x.x:35357/v2.0' --internalurl 'http://x.x.x.x:5000/v2.0'
>
> ** **
>
> And for swift:
>
> keystone service-create --name keystone --type=identity --description
> "Swift Storage Service"
>
> keystone endpoint-create --service-id $SWIFTSVC_ID --publicurl '
> http://x.x.x.x:8080/v1/AUTH_\$(tenant_id)s' --adminurl '
> http://x.x.x.x:8080/v1/AUTH_\$(tenant_id)s ' --internalurl '
> http://x.x.x.x:8080/v1/AUTH_\$(tenant_id)s '
>
> ** **
>
> Regards
>
> Brian
>
> ** **
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
+Hugo Kuo+
tonyt...@gmail.com
+ 886 935004793
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] [Sheepdog][Libvirt][Qemu]Add a new block storage driver by Libvirt/Qemu way for Openstack

[harryxiyou]

Hi all,

I wanna add a new block storage driver by Libvirt/Qemu way for Openstack, which
is as same as Sheepdog driver for Openstack. So i think the theories
are like this.

1, In the Openstack Nova branch, Openstck driver call libvirt client
and send parameters
to libvirt client.(From this point, i should modify Openstack Nova
source codes. They are
a, nova/nova/virt/libvirt/driver.pyadd new driver way
b, /OpenStack/nova/nova/tests/test_libvirt.py  add new driver test)

2, According to own protocol, libvirt client in Openstack Nova branch
send parameters to
Libvirt server.(From this point, i should modify libvirt library to
let libvirt library support this
new driver like Sheepdog).

3, Libvirt server call Qemu interfaces to send parameters to
Qemu.(From this point, i should
modify Qemu source codes to let Qemu support this new driver like Sheepdog).

4, In Openstack Cinder branch, Openstack driver use Qemu commands to
create this new volumes
to Qemu.(From this point, i should modify Openstack Cinder branch
source codes like this.
a, Add new driver file
/OpenStack/cinder/cinder/volume/drivers/new_driver.py like Sheepdog.py
b, Change file /OpenStack/cinder/cinder/tests/test_drivers_compatibility.py
to test new driver).

5, At last, i should also modify
/OpenStack/manuals/doc/src/docbkx/openstack-compute-admin/tables/hypervisors-nova-conf.xml
to configure this new driver.

Are my theories right? Should i do any other stuffs? Could anyone give
me any other suggestions?
Thanks in advance ;-)

-- 
Thanks
Harry Wei

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp