[virt-tools-list] virt-tools-list Digest, Vol 67, Issue 9

Scott Zupek szupek at gmail.com
Sat Jan 10 17:09:52 UTC 2015 

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, <virt-tools-list-request at redhat.com> wrote:

> Send virt-tools-list mailing list submissions to
>         virt-tools-list at redhat.com
>
> 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
>         virt-tools-list-request at redhat.com
>
> You can reach the person managing the list at
>         virt-tools-list-owner at redhat.com
>
> 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 <crobinso at redhat.com>
> To: Chen Hanxiao <chenhanxiao at cn.fujitsu.com>,
>         virt-tools-list at redhat.com
> Subject: Re: [virt-tools-list] [virt-manager PATCH] storagebrowse:
>         refresh storage pool when open browse window or selecting a new
> item
> Message-ID: <54B009F2.5020103 at redhat.com>
> 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 <gscrivan at redhat.com>
> To: Cole Robinson <crobinso at redhat.com>
> Cc: virt-tools-list at redhat.com
> Subject: Re: [virt-tools-list] [virt-manager PATCH] virtinst: do not
>         add     default channels if one is already present
> Message-ID: <87387jvpjo.fsf at redhat.com>
> Content-Type: text/plain
>
> Cole Robinson <crobinso at redhat.com> 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 <crobinso at redhat.com>
> To: Giuseppe Scrivano <gscrivan at redhat.com>
> Cc: virt-tools-list at redhat.com
> Subject: Re: [virt-tools-list] [virt-manager PATCH] virtinst: do not
>         add default channels if one is already present
> Message-ID: <54B00ED4.4010503 at redhat.com>
> Content-Type: text/plain; charset=us-ascii
>
> On 01/09/2015 12:20 PM, Giuseppe Scrivano wrote:
> > Cole Robinson <crobinso at redhat.com> 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
> virt-tools-list at redhat.com
> https://www.redhat.com/mailman/listinfo/virt-tools-list
>
> End of virt-tools-list Digest, Vol 67, Issue 9
> **********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20150110/2d78fc4b/attachment.htm>

More information about the virt-tools-list mailing list