What's the current status of running bridging through wireless adapters. Apple and windows all have an answer that requires no manual configuration. It would be nice if virt-manager were able to do the same. On Jan 10, 2015 11:02 AM, <[email protected]> wrote:
> Send virt-tools-list mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/virt-tools-list > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of virt-tools-list digest..." > > > Today's Topics: > > 1. Re: [virt-manager PATCH] storagebrowse: refresh storage pool > when open browse window or selecting a new item (Cole Robinson) > 2. Re: [virt-manager PATCH] virtinst: do not add default > channels if one is already present (Giuseppe Scrivano) > 3. Re: [virt-manager PATCH] virtinst: do not add default > channels if one is already present (Cole Robinson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 09 Jan 2015 12:03:46 -0500 > From: Cole Robinson <[email protected]> > To: Chen Hanxiao <[email protected]>, > [email protected] > Subject: Re: [virt-tools-list] [virt-manager PATCH] storagebrowse: > refresh storage pool when open browse window or selecting a new > item > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > Please read this email I sent regarding refreshing pools: > > http://www.redhat.com/archives/virt-tools-list/2014-December/msg00036.html > > On 12/22/2014 10:59 PM, Chen Hanxiao wrote: > > do a refresh operation when: > > a) open 'Locate or create storage volume' window > > b) select a new item in 'Storage Pools' list > > > > refresh is supposed to be a potentially long running operation, so > performing > it every time a pool is selected is not acceptable. There's an explicit > refresh button, people need to use that. > > Performing a refresh when launching the 'create volume' dialog should be > okay, > but stick it in createvol.py so it covers all cases > > - Cole > > > > ------------------------------ > > Message: 2 > Date: Fri, 09 Jan 2015 18:20:43 +0100 > From: Giuseppe Scrivano <[email protected]> > To: Cole Robinson <[email protected]> > Cc: [email protected] > Subject: Re: [virt-tools-list] [virt-manager PATCH] virtinst: do not > add default channels if one is already present > Message-ID: <[email protected]> > Content-Type: text/plain > > Cole Robinson <[email protected]> writes: > > > On 01/09/2015 06:29 AM, Giuseppe Scrivano wrote: > >> Closes: https://bugzilla.redhat.com/show_bug.cgi?id=1179680 > >> > > > > I don't think that test case would have triggered the original behavior, > you'd > > need to use the fake KVM URI, grep clitest.py for xml-comparison > > > > That said, I think the problem is elsewhere? That reproducing command > from the > > bug works fine on F21. The idea was that --channel none will turn off all > > default channels, but we only skip adding the spicevmc defaults if a > user has > > specified --channel spicevmc. So if someone is adding their own custom > > --channel pty, they don't have to re-specify the spicevmc one as well. > > > > Maybe it's non-intuitive but that's what the code does at the moment (we > > really need some explicit fine grained way of turning off individual > defaults > > but that's a larger effort). > > > > I'm not really sure where the error is coming from on RHEL... be useful > to see > > the full XML and qemu command line that is being generated. > > I was able to reproduce both using the libvirt upstream version and the > version on virt-preview. It seems that the problem is caused by the > fact that libvirt assigns the name "com.redhat.spice.0" to channels if > it is not already specified and this clashes with the spicevmc channel. > The generating this in libvirt seems to be old, git blame says 2013 for > the last change. Probably it is something changed in qemu that started > complaining if the same name is used more than once. > > Thinking more of it, probably the fix should go into libvirt, the XML > definition that causes the failure here looks like this (omitting > name="com.redhat.spice.0" does not make any difference): > > <domain type="kvm"> > <name>demo</name> > <uuid>5b7cb920-9d1e-440e-abab-47d353afafe0</uuid> > <memory>1048576</memory> > <currentMemory>1048576</currentMemory> > <vcpu>1</vcpu> > <os> > <type arch="x86_64">hvm</type> > <boot dev="hd"/> > </os> > <features> > <acpi/> > <apic/> > <pae/> > </features> > <cpu mode="custom" match="exact"> > <model>SandyBridge</model> > </cpu> > <clock offset="utc"> > <timer name="rtc" tickpolicy="catchup"/> > <timer name="pit" tickpolicy="delay"/> > <timer name="hpet" present="no"/> > </clock> > <on_poweroff>destroy</on_poweroff> > <on_reboot>restart</on_reboot> > <on_crash>restart</on_crash> > <devices> > <emulator>/bin/qemu-kvm</emulator> > <disk type="file" device="disk"> > <driver name="qemu" type="qcow2"/> > <source file="/var/lib/libvirt/images/demo.img"/> > <target dev="vda" bus="virtio"/> > </disk> > <controller type="usb" index="0" model="ich9-ehci1"/> > <controller type="usb" index="0" model="ich9-uhci1"> > <master startport="0"/> > </controller> > <controller type="usb" index="0" model="ich9-uhci2"> > <master startport="2"/> > </controller> > <controller type="usb" index="0" model="ich9-uhci3"> > <master startport="4"/> > </controller> > <interface type="network"> > <source network="default"/> > <mac address="52:54:00:b0:9c:fa"/> > <model type="virtio"/> > </interface> > <input type="tablet" bus="usb"/> > <graphics type="spice" port="-1" tlsPort="-1" autoport="yes"/> > <console type="pty"/> > <channel type="pty"> > <target type="virtio"/> > </channel> > <channel type="spicevmc"> > <target type="virtio" name="com.redhat.spice.0"/> > </channel> > <sound model="ich6"/> > <video> > <model type="qxl"/> > </video> > <redirdev bus="usb" type="spicevmc"/> > <redirdev bus="usb" type="spicevmc"/> > </devices> > </domain> > > Thanks, > Giuseppe > > > > ------------------------------ > > Message: 3 > Date: Fri, 09 Jan 2015 12:24:36 -0500 > From: Cole Robinson <[email protected]> > To: Giuseppe Scrivano <[email protected]> > Cc: [email protected] > Subject: Re: [virt-tools-list] [virt-manager PATCH] virtinst: do not > add default channels if one is already present > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > On 01/09/2015 12:20 PM, Giuseppe Scrivano wrote: > > Cole Robinson <[email protected]> writes: > > > >> On 01/09/2015 06:29 AM, Giuseppe Scrivano wrote: > >>> Closes: https://bugzilla.redhat.com/show_bug.cgi?id=1179680 > >>> > >> > >> I don't think that test case would have triggered the original > behavior, you'd > >> need to use the fake KVM URI, grep clitest.py for xml-comparison > >> > >> That said, I think the problem is elsewhere? That reproducing command > from the > >> bug works fine on F21. The idea was that --channel none will turn off > all > >> default channels, but we only skip adding the spicevmc defaults if a > user has > >> specified --channel spicevmc. So if someone is adding their own custom > >> --channel pty, they don't have to re-specify the spicevmc one as well. > >> > >> Maybe it's non-intuitive but that's what the code does at the moment (we > >> really need some explicit fine grained way of turning off individual > defaults > >> but that's a larger effort). > >> > >> I'm not really sure where the error is coming from on RHEL... be useful > to see > >> the full XML and qemu command line that is being generated. > > > > I was able to reproduce both using the libvirt upstream version and the > > version on virt-preview. It seems that the problem is caused by the > > fact that libvirt assigns the name "com.redhat.spice.0" to channels if > > it is not already specified and this clashes with the spicevmc channel. > > The generating this in libvirt seems to be old, git blame says 2013 for > > the last change. Probably it is something changed in qemu that started > > complaining if the same name is used more than once. > > > > Thinking more of it, probably the fix should go into libvirt, the XML > > definition that causes the failure here looks like this (omitting > > name="com.redhat.spice.0" does not make any difference): > > Ah I see. Yeah in that case I'd say libvirt continues to add the spice name > for type=spicevmc, but for any other channel it complains about missing > target > name. > > - Cole > > > > ------------------------------ > > _______________________________________________ > virt-tools-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/virt-tools-list > > End of virt-tools-list Digest, Vol 67, Issue 9 > ********************************************** >
_______________________________________________ virt-tools-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/virt-tools-list
