what a correct use for virConnectDomainEventRegisterAny API, how to Obtain a stable expected result
HI, everyone: My target deal with network hotplug use virDomainDetachDeviceFlags. Because when the API return ,the network maybe doesn’t remove from my vm guest os. So I use virConnectDomainEventRegisterAny to register an event ID: VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED , my process as follow: cb_para->call_id=virConnectDomainEventRegisterAny(cb_para->conn,cb_para->dom,VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED, VIR_DOMAIN_EVENT_CALLBACK(vnf_control_del_network_cb), cb_para, vnf_control_del_network_cb_free); flags |= VIR_DOMAIN_AFFECT_CONFIG; if (virDomainIsActive(dom) == 1) { flags |= VIR_DOMAIN_AFFECT_LIVE; } ret = virDomainDetachDeviceFlags(dom, xml, flags); above code write in thread loop ,then in the same loop : while (1) { mission = vnf_mission_queue_get(task); if (mission == NULL) { sleep(1); continue; } vnf_op_process(&mission->info); // this will deal with network hotplug,will call virConnectDomainEventRegisterAny then call virDomainDetachDeviceFlags if (mission) { vnf_mission_free(mission); } if(virEventRunDefaultImpl() < 0) { // at here process the registered callback for event-registered printf();.... } } My problem is: some time , the virEventRunDefaultImpl can trigger the vnf_control_del_network_cb callback ,but some time there is nothing ,as if the VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED has lost. what cause the Unpredictable behavior ? what is a correct use for virConnectDomainEventRegisterAny ? if can't trigger the vnf_control_del_network_cb callback , the memory :cb_para will mem-leak, so in order to deal the execpt ,i register a timer to process the VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED timeout cb_para->timer_id = virEventAddTimeout(cb_para->time_out, vnf_control_del_network_timeout_cb, cb_para, vnf_control_del_network_cb_free); thought use the timer ,can i avoid the cb_para mem-leak, but fail to achive hotplug network .
On Mon, Apr 13, 2020 at 05:32:38PM +0800, thomas.kuang wrote:
HI, everyone:
My target deal with network hotplug use virDomainDetachDeviceFlags. Because when the API return ,the network maybe doesn’t remove from my vm guest os.
So I use virConnectDomainEventRegisterAny to register an event ID: VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED ,
my process as follow:
cb_para->call_id=virConnectDomainEventRegisterAny(cb_para->conn,cb_para->dom,VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED, VIR_DOMAIN_EVENT_CALLBACK(vnf_control_del_network_cb), cb_para, vnf_control_del_network_cb_free);
flags |= VIR_DOMAIN_AFFECT_CONFIG; if (virDomainIsActive(dom) == 1) { flags |= VIR_DOMAIN_AFFECT_LIVE; }
ret = virDomainDetachDeviceFlags(dom, xml, flags);
above code write in thread loop ,then in the same loop :
while (1) {
mission = vnf_mission_queue_get(task);
if (mission == NULL) {
sleep(1);
continue;
}
vnf_op_process(&mission->info); // this will deal with network hotplug,will call virConnectDomainEventRegisterAny then call virDomainDetachDeviceFlags
if (mission) {
vnf_mission_free(mission);
}
if(virEventRunDefaultImpl() < 0) { // at here process the registered callback for event-registered
printf();....
}
}
My problem is: some time , the virEventRunDefaultImpl can trigger the vnf_control_del_network_cb callback ,but some time there is nothing, as if the VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED has lost. what cause the Unpredictable behavior ? what is a correct use for virConnectDomainEventRegisterAny ?
The virDomainDetachDeviceFlags API is asynchronous and requires a cooperative guest to complete. It merely injects an ACPI PCI unplug request to the guest OS. If the guest OS doesn't honour this request (because it is in early bootup, or is in BIOS, or is crashed, or is configured to disable hotplug, or is maliciously not responding), then the device will never be unplugged, and so you'll never get an event. So the first thing for you todo is to validate that the device really is being unplugged in the guest OS, and in QEMU. To check QEMU run: virsh qemu-monitor-command --hmp $GUEST "info pci" and look to see if the PCI device is still listed in the output. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Daniel, thanks for your help. If it cannot receive a stable expected callback, it need a timer to handle the timeout, in the timer timeout to release memory passed to virConnectDomainEventRegisterAny or, maybe memory-leak now ... At 2020-04-14 18:00:49, "Daniel P. Berrangé" <berrange@redhat.com> wrote:
On Mon, Apr 13, 2020 at 05:32:38PM +0800, thomas.kuang wrote:
HI, everyone:
My target deal with network hotplug use virDomainDetachDeviceFlags. Because when the API return ,the network maybe doesn’t remove from my vm guest os.
So I use virConnectDomainEventRegisterAny to register an event ID: VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED ,
my process as follow:
cb_para->call_id=virConnectDomainEventRegisterAny(cb_para->conn,cb_para->dom,VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED, VIR_DOMAIN_EVENT_CALLBACK(vnf_control_del_network_cb), cb_para, vnf_control_del_network_cb_free);
flags |= VIR_DOMAIN_AFFECT_CONFIG; if (virDomainIsActive(dom) == 1) { flags |= VIR_DOMAIN_AFFECT_LIVE; }
ret = virDomainDetachDeviceFlags(dom, xml, flags);
above code write in thread loop ,then in the same loop :
while (1) {
mission = vnf_mission_queue_get(task);
if (mission == NULL) {
sleep(1);
continue;
}
vnf_op_process(&mission->info); // this will deal with network hotplug,will call virConnectDomainEventRegisterAny then call virDomainDetachDeviceFlags
if (mission) {
vnf_mission_free(mission);
}
if(virEventRunDefaultImpl() < 0) { // at here process the registered callback for event-registered
printf();....
}
}
My problem is: some time , the virEventRunDefaultImpl can trigger the vnf_control_del_network_cb callback ,but some time there is nothing, as if the VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED has lost. what cause the Unpredictable behavior ? what is a correct use for virConnectDomainEventRegisterAny ?
The virDomainDetachDeviceFlags API is asynchronous and requires a cooperative guest to complete. It merely injects an ACPI PCI unplug request to the guest OS. If the guest OS doesn't honour this request (because it is in early bootup, or is in BIOS, or is crashed, or is configured to disable hotplug, or is maliciously not responding), then the device will never be unplugged, and so you'll never get an event.
So the first thing for you todo is to validate that the device really is being unplugged in the guest OS, and in QEMU.
To check QEMU run:
virsh qemu-monitor-command --hmp $GUEST "info pci"
and look to see if the PCI device is still listed in the output.
Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
participants (2)
-
Daniel P. Berrangé -
thomas.kuang