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