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 <[email protected]> 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 <[email protected]>wrote: > >> On Wed, Sep 5, 2012 at 8:45 PM, Eric Blake <[email protected]> wrote: >> > On 09/05/2012 09:08 AM, Bharata B Rao wrote: >> >> On Wed, Sep 5, 2012 at 7:03 PM, Jiri Denemark <[email protected]> >> 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 >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/gluster-devel >> > >
_______________________________________________ Gluster-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/gluster-devel
