On 11/7/18 8:17 AM, Han Han wrote:
On Tue, Nov 6, 2018 at 6:29 AM John Ferlan <jferlan(a)redhat.com
<mailto:jferlan@redhat.com>> wrote:
On 10/12/18 4:50 AM, Han Han wrote:
>
https://bugzilla.redhat.com/show_bug.cgi?id=1375423
>
> Signed-off-by: Han Han <hhan(a)redhat.com <mailto:hhan@redhat.com>>
> ---
> src/conf/domain_conf.c | 30 ++++++++++++++++++++++++++++++
> src/conf/domain_conf.h | 3 +++
> src/libvirt_private.syms | 1 +
> src/qemu/qemu_driver.c | 10 +++++++++-
> 4 files changed, 43 insertions(+), 1 deletion(-)
>
I assume no concerns over something that could be attached to a port on
the hub... I guess for a cold unplug it probably won't matter so much.
For the usb hub coldunplug, I find a concern. If a usb device attatched
to a usb-hub, then we coldunplug the hub, how will the hub and usb device
look like? All disappear OR all remain?
Since you've posted the patches, then I would hope you could answer your
own question regarding what happens.
Still in a way this is different than hot/live unplug. Attempting to
start the guest after you've removed a hub that had defined/listed USB
address/attachments would I assume fail because the hub is gone. But
there is a little self doubt because of the automatic hub add algorithm
pointed out in patch 7.
If it does expectedly fail, then someone would have to cold plug a new
device in using the correct address before booting - which is an
expected operation.
In a way no different that someone changing a guest config to use 100
vCPUs or 100G on a host that couldn't support those amounts. When cold
changing things, as long as the value is valid - we're good. When
starting if we don't have the resources, then we're not so good
John
As I know, for scsi and scsi controllers, it is all remaining :)
Reviewed-by: John Ferlan <jferlan(a)redhat.com
<mailto:jferlan@redhat.com>>
John
--
Best regards,
-----------------------------------
Han Han
Quality Engineer
Redhat.
Email: hhan(a)redhat.com <mailto:hhan@redhat.com>
Phone: +861065339333