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

[Yin Yin]

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/a7732029/attachment-0004.html>