[Gluster-devel] [libvirt] [RFC PATCH v1 1/2] Qemu/Gluster: Add Gluster protocol as supported network disk formats.

[Yin Yin]

sorry,
disk.1 should be:
disk.1: create from disk.0 backing file: gluster://
127.0.0.1:24007/vms/disk.0 (actual path: gluster://
127.0.0.1:24007/vms/disk.0)

On Fri, Sep 7, 2012 at 12:35 AM, Yin Yin <maillistofyinyin at gmail.com> wrote:

> Hi,All:
>      has anyone test qcow2+virtio+back_file+ qemu-gluster ?
>      disk.0: win7 guest, file format qcow2 , with virtio dirver
>      disk.1: create from disk.0 backing file: gluster://
> 127.0.0.1:24007/vms/windows7-32-qcow2.img (actual path: gluster://
> 127.0.0.1:24007/vms/windows7-32-qcow2.img)
>      libvirt config file:
>                      <disk type='network' device='disk'>
>                         <source protocol='gluster' name='vms/disk.1'>
>                                 <host name='127.0.0.1' port='24007'/>
>                         </source>
>                         <target dev='vda' bus='virtio'/>
>                         <driver name='qemu' type='qcow2' io='native'
> cache='none'/>
>                 </disk>
>       virsh create vm.xml
>       the win7 vm will boot first time, then it begin to install virtio
> driver control, then it ask to reboot. but after the vm reboot, the win7
> came into recovery mode, and can't boot.
>      I can boot from win7 from disk.0 reboot anytime without any error.
>      I can boot from win7 from disk.1 without virtio( just   <target
> dev='hda'/> ) reboot anytime without any error too, just boot slowly.
>      has anyone test this?
>
> Best Regards,
> Yin Yin
>
>
> On Thu, Sep 6, 2012 at 11:24 PM, Bharata B Rao <bharata.rao at gmail.com>wrote:
>
>> On Wed, Sep 5, 2012 at 8:45 PM, Eric Blake <eblake at redhat.com> wrote:
>> > On 09/05/2012 09:08 AM, Bharata B Rao wrote:
>> >> On Wed, Sep 5, 2012 at 7:03 PM, Jiri Denemark <jdenemar at redhat.com>
>> wrote:
>> >>>> @@ -1042,6 +1043,13 @@
>> >>>>                      <attribute name="port">
>> >>>>                        <ref name="unsignedInt"/>
>> >>>>                      </attribute>
>> >>>> +                    <attribute name="transport">
>> >>>> +                      <choice>
>> >>>> +                        <value>socket</value>
>> >>>> +                        <value>unix</value>
>> >>>> +                        <value>rdma</value>
>> >>>
>> >>> This could be a bit confusing as socket is too generic, after all
>> unix is also
>> >>> a socket. Could we change the values "tcp", "unix", "rdma" or
>> something
>> >>> similar depending on what "socket" was supposed to mean?
>> >>
>> >> That is how gluster calls it and hence I am using the same in QEMU and
>> >> the same is true here too. This is something for gluster developers to
>> >> decide if they want to change socket to something more specific like
>> >> tcp as you suggest.
>> >
>> > Just because gluster calls it a confusing name does not mean we have to
>> > repeat the confusion in libvirt - it is feasible to have a mapping where
>> > we name it 'tcp' in the XML but map that to 'socket' in the command line
>> > that eventually reaches gluster.  The question then becomes whether
>> > using sensible naming in libvirt, but no longer directly mapped to
>> > underlying gluster naming, will be the cause of its own set of
>> headaches.
>>
>> Vijay - would really like to have your inputs here...
>>
>> - While the transport-type for a volume is shown as tcp in "gluster
>> volume info", libgfapi forces me to use transport=socket to access the
>> same volume from QEMU. So does "socket" mean "tcp" really ? If so,
>> should I just switch over to using transport=tcp from QEMU ? If not,
>> can you explain a bit about the difference b/n socket and tcp
>> transport types ?
>>
>> - Also apart from socket (or tcp ?), rdma and unix, are there any
>> other transport options that QEMU should care about ?
>>
>> - Are rdma and unix transport types operational at the moment ? If
>> not, do you see them being used in gluster any time in the future ?
>> The reason behind asking this is to check if we are spending effort in
>> defining semantics in QEMU for a transport type that is never going to
>> be used in gluster. Also I see that "gluster volume create" supports
>> tcp and rdma but doesn't list unix as an option.
>>
>> Regards,
>> Bharata.
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/gluster-devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20120907/c7f9914b/attachment-0005.html>