On 11/7/18 8:17 AM, Han Han wrote:
On Tue, Nov 6, 2018 at 6:29 AM John Ferlan <jferlan@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@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@redhat.com <mailto:jferlan@redhat.com>>
John
-- Best regards, ----------------------------------- Han Han Quality Engineer Redhat.
Email: hhan@redhat.com <mailto:hhan@redhat.com> Phone: +861065339333