Re: [libvirt] [PATCH v4 4/4] auto-create pci-bridge controller info
在 2013-03-06三的 13:13 +0800，li guang写道： > 在 2013-03-05二的 10:36 +，Daniel P. Berrange写道： > > On Mon, Mar 04, 2013 at 02:39:40PM -0500, Laine Stump wrote: > > > On 03/04/2013 11:51 AM, Ján Tomko wrote: > > > > On 02/19/13 03:25, liguang wrote: > > > >> if some devices specify a pci bus number that > > > >> haven't been defined by a pci-bridge controller > > > >> then fill the required correct controller info > > > >> silently. > > > >> > > > >> Acked-by: Daniel P. Berrange > > > >> Signed-off-by: liguang > > > >> --- > > > > This will only add bridges for the explictly mentioned buses, which > > > > would mean we could have buses 0 and 6 with no buses between them. > > > > Maybe we should add them the way we add disk controllers - find the > > > > highest index and add all bridges with indexes from 1 to max. > > > > > > But each pci bridge device takes up another slot, which we may not want > > > to give up. (Although arguably, once we have pci-bridge devices, we can > > > create as many slots as we like :-) > > > > > > > > > Is there some advantage to having all the buses filled in (other than > > > similarity to what's done for other types of controllers)? > > > > > > > It would be nice if we could add pci bridges even when there weren't any > > > > specified in the XML, but there are too many PCI devices. I don't know > > > > what would be the nicest way to do that. > > > > > > If we auto-assign addresses for un-addressed devices first (your recent > > > patches did that, right? I forget the status of those), *then* > > > auto-create the required bridges (which themselves will need an > > > auto-assigned address), that should just happen. > > > > > > Of course, if we do that, then we won't have reserved any slots on bus 0 > > > for even a single pci-bridge device, so we'll fail. Is the proper way > > > out of this to always reserve one (or maybe two, for good measure) slots > > > on any given bus to be used only for bridges? That way no matter how out > > > of hand things get, we'll always have a place we can add another bus. > > > (In the case of *lots* of devices, I assume that a device on a nested > > > PCI bridge would be less efficient, and may have some other limitations, > > > but it would be better than nothing. And if the admin was really > > > concerned about that, they could modify their config to explicitly place > > > several bridges directly on bus 0) > > > > You'd have todo a 2 pass assignment. First count the number of devices > > that need to have PCI addresses assigned. Then create the required > > number of bridges, then assign the addresses. > > > > All this time though, bear in mind that auto-address assignment is just > > a convenience. At some point we are well within our right to stop and > > say this is as good as its going to get, you must do address assignment > > if the app if you want something more clever. > > > > > This also brings up the fact that we need to deal with the possibility > > > of all buses being full during hotplug - when that happens I suppose we > > > will also want to auto-add a pci bridge. > > > > Well if buses are all full, there's no where to hook in the bridge :-) > > So you need to do that before filling up, or just say this is out of > > scope and the app must explicitly plug a bridge if they want more space. > > Hmm, it's good point that haven't been considered by me, > so, do I have to hack into device hot-plug to know if > bus slot is almost exhausted and decide whether add pci-bridge or not? > or, just let user bear in mind that? > So ... , what should I do next? and what about other 3 patches? > > > > > > Daniel > > -- > > |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ > > :| > > |: http://libvirt.org -o- http://virt-manager.org > > :| > > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ > > :| > > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc > > :| > > > > -- > > libvir-list mailing list > > libvir-list@redhat.com > > https://www.redhat.com/mailman/listinfo/libvir-list > > > > -- > libvir-list mailing list > libvir-list@redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v4 4/4] auto-create pci-bridge controller info
在 2013-03-05二的 10:36 +，Daniel P. Berrange写道： > On Mon, Mar 04, 2013 at 02:39:40PM -0500, Laine Stump wrote: > > On 03/04/2013 11:51 AM, Ján Tomko wrote: > > > On 02/19/13 03:25, liguang wrote: > > >> if some devices specify a pci bus number that > > >> haven't been defined by a pci-bridge controller > > >> then fill the required correct controller info > > >> silently. > > >> > > >> Acked-by: Daniel P. Berrange > > >> Signed-off-by: liguang > > >> --- > > > This will only add bridges for the explictly mentioned buses, which > > > would mean we could have buses 0 and 6 with no buses between them. > > > Maybe we should add them the way we add disk controllers - find the > > > highest index and add all bridges with indexes from 1 to max. > > > > But each pci bridge device takes up another slot, which we may not want > > to give up. (Although arguably, once we have pci-bridge devices, we can > > create as many slots as we like :-) > > > > > > Is there some advantage to having all the buses filled in (other than > > similarity to what's done for other types of controllers)? > > > > > It would be nice if we could add pci bridges even when there weren't any > > > specified in the XML, but there are too many PCI devices. I don't know > > > what would be the nicest way to do that. > > > > If we auto-assign addresses for un-addressed devices first (your recent > > patches did that, right? I forget the status of those), *then* > > auto-create the required bridges (which themselves will need an > > auto-assigned address), that should just happen. > > > > Of course, if we do that, then we won't have reserved any slots on bus 0 > > for even a single pci-bridge device, so we'll fail. Is the proper way > > out of this to always reserve one (or maybe two, for good measure) slots > > on any given bus to be used only for bridges? That way no matter how out > > of hand things get, we'll always have a place we can add another bus. > > (In the case of *lots* of devices, I assume that a device on a nested > > PCI bridge would be less efficient, and may have some other limitations, > > but it would be better than nothing. And if the admin was really > > concerned about that, they could modify their config to explicitly place > > several bridges directly on bus 0) > > You'd have todo a 2 pass assignment. First count the number of devices > that need to have PCI addresses assigned. Then create the required > number of bridges, then assign the addresses. > > All this time though, bear in mind that auto-address assignment is just > a convenience. At some point we are well within our right to stop and > say this is as good as its going to get, you must do address assignment > if the app if you want something more clever. > > > This also brings up the fact that we need to deal with the possibility > > of all buses being full during hotplug - when that happens I suppose we > > will also want to auto-add a pci bridge. > > Well if buses are all full, there's no where to hook in the bridge :-) > So you need to do that before filling up, or just say this is out of > scope and the app must explicitly plug a bridge if they want more space. Hmm, it's good point that haven't been considered by me, so, do I have to hack into device hot-plug to know if bus slot is almost exhausted and decide whether add pci-bridge or not? or, just let user bear in mind that? > > > Daniel > -- > |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| > > -- > libvir-list mailing list > libvir-list@redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v4 0/4] add pci-bridge support
Hi, any other comments? 在 2013-02-25一的 09:38 +0800，li guang写道： > ping ... > > 在 2013-02-19二的 10:25 +0800，liguang写道： > > Now, it's impossible to arrange devices into multi-pci-bus, > > for example: > > > >> function='0x0'/> > > > > > > > >> function='0x0'/> > > > > libvirt will complain about "bus != 0", > > fortunately, qemu supports pci-to-pci bridge, > > if we want to use multi-pci-bus, we can define > > 2 pci bridge controllers, then attach 1 to the other > > as a subordinate pci-bus, so, 2 pci-buses appear. > > for example: > > > > > >> function='0x0'/> > > > > > >> function='0x0'/> > > > > > > > >> function='0x0'/> > > > > > > > > src/conf/domain_conf.c| 98 - > > src/conf/domain_conf.h|1 + > > docs/schemas/domaincommon.rng |1 + > > src/qemu/qemu_capabilities.c |4 + > > src/qemu/qemu_capabilities.h |1 + > > src/qemu/qemu_command.c | 43 - > > 6 files changed, 126 insertions(+), 22 deletions(-) > -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] wrap some long lines
ping ...
在 2013-02-19二的 10:22 +0800，liguang写道：
> Signed-off-by: liguang
> ---
> src/qemu/qemu_command.c | 71 ++
> 1 files changed, 46 insertions(+), 25 deletions(-)
>
> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
> index 9ad3c77..ad62120 100644
> --- a/src/qemu/qemu_command.c
> +++ b/src/qemu/qemu_command.c
> @@ -611,7 +611,8 @@ qemuAssignDeviceNetAlias(virDomainDefPtr def,
> virDomainNetDefPtr net, int idx)
> }
> if ((thisidx = qemuDomainDeviceAliasIndex(&def->nets[i]->info,
> "net")) < 0) {
> virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> - _("Unable to determine device index for
> network device"));
> + _("Unable to determine device index for "
> + "network device"));
> return -1;
> }
> if (thisidx >= idx)
> @@ -638,7 +639,8 @@ qemuAssignDeviceHostdevAlias(virDomainDefPtr def,
> virDomainHostdevDefPtr hostdev
> int thisidx;
> if ((thisidx =
> qemuDomainDeviceAliasIndex(def->hostdevs[i]->info, "hostdev")) < 0) {
> virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> - _("Unable to determine device index for
> hostdev device"));
> + _("Unable to determine device index for "
> + "hostdev device"));
> return -1;
> }
> if (thisidx >= idx)
> @@ -665,7 +667,8 @@ qemuAssignDeviceRedirdevAlias(virDomainDefPtr def,
> virDomainRedirdevDefPtr redir
> int thisidx;
> if ((thisidx =
> qemuDomainDeviceAliasIndex(&def->redirdevs[i]->info, "redir")) < 0) {
> virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> - _("Unable to determine device index for
> redirected device"));
> + _("Unable to determine device index for"
> + " redirected device"));
> return -1;
> }
> if (thisidx >= idx)
> @@ -1001,8 +1004,8 @@ static int qemuCollectPCIAddress(virDomainDefPtr def
> ATTRIBUTE_UNUSED,
> if (info->addr.pci.function != 0) {
> virReportError(VIR_ERR_XML_ERROR,
> _("Attempted double use of PCI Address '%s' "
> - "(may need \"multifunction='on'\" for device on
> function 0)"),
> - addr);
> + "(may need \"multifunction='on'\" for "
> + "device on function 0)"), addr);
> } else {
> virReportError(VIR_ERR_XML_ERROR,
> _("Attempted double use of PCI Address '%s'"),
> addr);
> @@ -1036,7 +1039,8 @@ static int qemuCollectPCIAddress(virDomainDefPtr def
> ATTRIBUTE_UNUSED,
> goto cleanup;
> }
>
> -VIR_DEBUG("Remembering PCI addr %s (multifunction=off for
> function 0)", addr);
> +VIR_DEBUG("Remembering PCI addr %s (multifunction=off"
> + " for function 0)", addr);
> if (virHashAddEntry(addrs->used, addr, addr))
> goto cleanup;
> addr = NULL;
> @@ -1468,7 +1472,8 @@ qemuAssignDevicePCISlots(virDomainDefPtr def,
> def->controllers[i]->info.addr.pci.slot != 1 ||
> def->controllers[i]->info.addr.pci.function != 2) {
> virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> - _("PIIX3 USB controller must have PCI
> address 0:0:1.2"));
> + _("PIIX3 USB controller must have"
> + " PCI address 0:0:1.2"));
> goto error;
> }
> reservedUSB = true;
> @@ -1524,7 +1529,8 @@ qemuAssignDevicePCISlots(virDomainDefPtr def,
> primaryVideo->info.addr.pci.slot != 2 ||
> primaryVideo->info.addr.pci.function != 0) {
> virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> - _("Primary video card must have PCI address
> 0:0:2.0"));
> + _("Primary video card must have "
> + "PCI address 0:0:2.0"));
> goto error;
> }
> /* If TYPE==PCI, then qemuCollectPCIAddress() function
> @@ -1814,12 +1820,14 @@ qemuBuildRomStr(virBufferPtr buf,
> if (info->rombar || info->romfile) {
> if (info->type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI) {
> virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
> - "%s", _("rombar and romfile are supported only
> for PCI devices"));
> + "%s", _("rombar and romfile are supp
Re: [libvirt] [PATCH v4 0/4] add pci-bridge support
ping ... 在 2013-02-19二的 10:25 +0800，liguang写道： > Now, it's impossible to arrange devices into multi-pci-bus, > for example: > >function='0x0'/> > > > >function='0x0'/> > > libvirt will complain about "bus != 0", > fortunately, qemu supports pci-to-pci bridge, > if we want to use multi-pci-bus, we can define > 2 pci bridge controllers, then attach 1 to the other > as a subordinate pci-bus, so, 2 pci-buses appear. > for example: > > >function='0x0'/> > > >function='0x0'/> > > > >function='0x0'/> > > > > src/conf/domain_conf.c| 98 - > src/conf/domain_conf.h|1 + > docs/schemas/domaincommon.rng |1 + > src/qemu/qemu_capabilities.c |4 + > src/qemu/qemu_capabilities.h |1 + > src/qemu/qemu_command.c | 43 - > 6 files changed, 126 insertions(+), 22 deletions(-) -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [rebased][PATCH 2/4] build command line for pci-bridge device of qemu
在 2013-02-05二的 17:53 +0100，Ján Tomko写道：
> On 01/30/13 03:30, liguang wrote:
> > @@ -974,8 +967,24 @@ static char
> > *qemuPCIAddressAsString(virDomainDeviceInfoPtr dev)
> > return addr;
> > }
> >
> > +static int qemuPciBridgeSupport(virDomainDefPtr def)
> > +{
> > +int i, c = 0;
> > +
> > +for (i = 0; i < def->ncontrollers; i++) {
> > +virDomainControllerDefPtr controller = def->controllers[i];
> > +
> > +if (controller->type == VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE)
> > +c++;
> > +}
> >
> > -static int qemuCollectPCIAddress(virDomainDefPtr def ATTRIBUTE_UNUSED,
> > +if (c > 1)
> > +return 0;
> > +else
> > +return -1;
> > +}
> > +
>
> This function is pointless if we're going to auto-add the bridges.
Yes, good catch!
>
> > @@ -1002,7 +1025,8 @@ static int qemuCollectPCIAddress(virDomainDefPtr def
> > ATTRIBUTE_UNUSED,
> > if (info->addr.pci.function != 0) {
> > virReportError(VIR_ERR_XML_ERROR,
> > _("Attempted double use of PCI Address '%s' "
> > - "(may need \"multifunction='on'\" for device
> > on function 0)"),
> > + "(may need \"multifunction='on'\" for "
> > + "device on function 0)"),
> > addr);
> > } else {
> > virReportError(VIR_ERR_XML_ERROR,
> > @@ -1037,7 +1061,8 @@ static int qemuCollectPCIAddress(virDomainDefPtr def
> > ATTRIBUTE_UNUSED,
> > goto cleanup;
> > }
> >
> > -VIR_DEBUG("Remembering PCI addr %s (multifunction=off for
> > function 0)", addr);
> > +VIR_DEBUG("Remembering PCI addr %s (multifunction=off"
> > + " for function 0)", addr);
> > if (virHashAddEntry(addrs->used, addr, addr))
> > goto cleanup;
> > addr = NULL;
>
> These two long-line wraps belong to a separate patch.
OK, will move to another patch for long line wraps.
>
> > @@ -3072,6 +3090,12 @@ qemuBuildControllerDevStr(virDomainDefPtr domainDef,
> > int model;
> >
> > switch (def->type) {
> > +case VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE:
> > +virBufferAsprintf(&buf, "pci-bridge,chassis_nr=%d", def->idx+1);
> > +virBufferAsprintf(&buf, ",id=pci.%d", def->idx);
> > +if (def->idx == 0)
>
> We should report an error instead of creating a bridge with name 'pci.0'
> that can't be used.
OK, Thanks!
>
> > +goto out;
> > +break;
> > case VIR_DOMAIN_CONTROLLER_TYPE_SCSI:
> > model = def->model;
> > if ((qemuSetScsiControllerModel(domainDef, caps, &model)) < 0)
>
> Jan
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [rebased][PATCH 1/4] add pci-bridge controller type
sorry for late reply.
在 2013-02-05二的 16:56 +，Daniel P. Berrange写道：
> On Tue, Feb 05, 2013 at 05:53:30PM +0100, Ján Tomko wrote:
> > On 01/30/13 03:30, liguang wrote:
> > > @@ -4493,6 +4494,8 @@ virDomainControllerDefParseXML(xmlNodePtr node,
> > > goto error;
> > >
> > > switch (def->type) {
> > > +case VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE:
> > > +break;
> > > case VIR_DOMAIN_CONTROLLER_TYPE_VIRTIO_SERIAL: {
> > > char *ports = virXMLPropString(node, "ports");
> > > if (ports) {
> >
> > This hunk doesn't do anything and can be dropped.
> >
> > > diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
> > > index 9a9e0b1..a93562d 100644
> > > --- a/src/conf/domain_conf.h
> > > +++ b/src/conf/domain_conf.h
> > > @@ -661,6 +661,7 @@ enum virDomainControllerType {
> > > VIR_DOMAIN_CONTROLLER_TYPE_VIRTIO_SERIAL,
> > > VIR_DOMAIN_CONTROLLER_TYPE_CCID,
> > > VIR_DOMAIN_CONTROLLER_TYPE_USB,
> > > +VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE,
> > >
> > > VIR_DOMAIN_CONTROLLER_TYPE_LAST
> > > };
> > >
> > VIR_DOMAIN_CONTROLLER_TYPE_PCI_BRIDGE would be nicer. Or maybe just
> > VIR_DOMAIN_CONTROLLER_TYPE_PCI would do.
>
> FYI, PCI_BRIDGE is better, because in the future we'll have the option
> of multiple PCI roots, implying a CONTROLLER_TYPE_PCI_ROOT or something
> like that
I think what you called "multiple PCI roots" is pci root bridge, isn't
it? so, do we need a new controller name?
>
> Daniel
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [rebased][PATCH 1/4] add pci-bridge controller type
sorry for late reply.
在 2013-02-05二的 17:53 +0100，Ján Tomko写道：
> On 01/30/13 03:30, liguang wrote:
> > @@ -4493,6 +4494,8 @@ virDomainControllerDefParseXML(xmlNodePtr node,
> > goto error;
> >
> > switch (def->type) {
> > +case VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE:
> > +break;
> > case VIR_DOMAIN_CONTROLLER_TYPE_VIRTIO_SERIAL: {
> > char *ports = virXMLPropString(node, "ports");
> > if (ports) {
>
> This hunk doesn't do anything and can be dropped.
hmm, it's just for showing,
compiler will generate nothing for it.
so is it necessary to remove it?
>
> > diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
> > index 9a9e0b1..a93562d 100644
> > --- a/src/conf/domain_conf.h
> > +++ b/src/conf/domain_conf.h
> > @@ -661,6 +661,7 @@ enum virDomainControllerType {
> > VIR_DOMAIN_CONTROLLER_TYPE_VIRTIO_SERIAL,
> > VIR_DOMAIN_CONTROLLER_TYPE_CCID,
> > VIR_DOMAIN_CONTROLLER_TYPE_USB,
> > +VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE,
> >
> > VIR_DOMAIN_CONTROLLER_TYPE_LAST
> > };
> >
> VIR_DOMAIN_CONTROLLER_TYPE_PCI_BRIDGE would be nicer. Or maybe just
> VIR_DOMAIN_CONTROLLER_TYPE_PCI would do.
I think we should clarify the difference between PCI and PCIBRIDGE.
>
> Jan
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [rebased][PATCH 0/4] add pci-bridge support
ping ... 在 2013-01-30三的 10:30 +0800，liguang写道： > Now, it's impossible to arrange devices into multi-pci-bus, > for example: > >function='0x0'/> > > > >function='0x0'/> > > libvirt will complain about "bus != 0", > fortunately, qemu supports pci-to-pci bridge, > if we want to use multi-pci-bus, we can define > 2 pci bridge controllers, then attach 1 to the other > as a subordinate pci-bus, so, 2 pci-buses appear. > for example: > > >function='0x0'/> > > >function='0x0'/> > > > >function='0x0'/> > > > > src/conf/domain_conf.c|100 - > src/conf/domain_conf.h|1 + > docs/schemas/domaincommon.rng |1 + > src/qemu/qemu_capabilities.c |2 + > src/qemu/qemu_capabilities.h |1 + > src/qemu/qemu_command.c | 70 - > 6 files changed, 152 insertions(+), 23 deletions(-) -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 0/3] add pci-bridge support
Hi, All any other comments? 在 2013-01-14一的 11:42 +0800，li guang写道： > ping ... > > 在 2013-01-10四的 09:04 +0800，liguang写道： > > Now, it's impossible to arrange devices into multi-pci-bus, > > for example: > > > >> function='0x0'/> > > > > > > > >> function='0x0'/> > > > > libvirt will complain about "bus != 0", > > fortunately, qemu supports pci-to-pci bridge, > > if we want to use multi-pci-bus, we can define > > 2 pci bridge controllers, then attach 1 to the other > > as a subordinate pci-bus, so, 2 pci-buses appear. > > for example: > > > > > >> function='0x0'/> > > > > > >> function='0x0'/> > > > > > > > >> function='0x0'/> > > > > > > > > src/conf/domain_conf.c|5 - > > src/conf/domain_conf.h|1 + > > docs/schemas/domaincommon.rng |1 + > > src/qemu/qemu_capabilities.c |2 + > > src/qemu/qemu_capabilities.h |1 + > > src/qemu/qemu_command.c | 70 - > > 6 files changed, 57 insertions(+), 23 deletions(-) > -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] auto-create pci-bridge controller info
在 2013-01-23三的 10:05 +，Daniel P. Berrange写道： > On Wed, Jan 23, 2013 at 09:45:20AM +0800, liguang wrote: > > if some devices specify a pci bus number that > > haven't been defined by a pci-bridge controller > > then fill the required correct controller info > > silently. > > it based on previous add pci-bridge support patches, > > https://www.redhat.com/archives/libvir-list/2013-January/msg00577.html > > > > Signed-off-by: liguang > > --- > > src/conf/domain_conf.c | 95 > > > > 1 files changed, 95 insertions(+), 0 deletions(-) > > ACK > > Daniel Thanks! -- regards! li guang -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH RFC] auto-create pci-bridge controller info
E_PCIBRIDGE,
+ idx) < 0)
+return -1;
+}
+
+for (i = 0; i < def->nhostdevs; i++) {
+if (def->hostdevs[i]->info->type !=
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI)
+continue;
+idx = def->hostdevs[i]->info->addr.pci.bus;
+ if (virDomainDefMaybeAddController(def,
+
VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE,
+ idx) < 0)
+return -1;
+}
+
+for (i = 0; i < def->ndisks; i++) {
+if (def->disks[i]->info.type !=
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI)
+continue;
+idx = def->disks[i]->info.addr.pci.bus;
+if (virDomainDefMaybeAddController(def,
+
VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE,
+ idx) < 0)
+return -1;
+}
+
if (def->watchdog->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI)
idx = def->watchdog->info.addr.pci.bus;
>
> Regards,
> Daniel
--
regards!
li guang
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 2/3] build command line for pci-bridge device of qemu
在 2013-01-16三的 09:26 +，Daniel P. Berrange写道：
> On Wed, Jan 16, 2013 at 04:24:55PM +0800, li guang wrote:
> > 在 2013-01-15二的 09:27 +，Daniel P. Berrange写道：
> > > On Mon, Jan 14, 2013 at 05:23:54PM +0100, Ján Tomko wrote:
> > > > On 01/10/13 02:04, liguang wrote:
> > > >
> > > > This would allow any bus number, even if we don't have enough PCI
> > > > bridges. It is also not the only place where qemuPCIAddressAsString is
> > > > called from and where this needs to be checked.
> > >
> > > With other types of addresses, we will auto-create the
> > > elements if we find the controller does not exist. We should probably
> > > do the same for PCI. ie if you have bus == 2 and no PCI bridge for
> > > that bus exists, then add one.
> >
> > Oh, this amazing feature will remove all the need of
> > controller pre-definition in domain's XML file, will it?
> > could you please give me an already exist example?
> > just can't find them by a quick search.
>
> Take a look at the virDomainDefAddImplicitControllers method in
> domain_conf.c
>
> Regards,
> Daniel
Hi, Daniel
do you like following changes:
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 8ebe77d..988e4f2 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -11756,6 +11756,60 @@
virDomainDefMaybeAddSmartcardController(virDomainDefPtr def)
}
+static int
+virDomainDefMaybeAddPcibridgeController(virDomainDefPtr def)
+{
+int i, idx = 0;
+
+for (i = 0; i < def->nnets; i++) {
+if (def->nets[i]->info.type !=
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI)
+continue;
+idx = def->nets[i]->info.addr.pci.bus;
+if (virDomainDefMaybeAddController(def,
+
VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE,
+ idx) < 0)
+return -1;
+}
+
+for (i = 0; i < def->nsounds; i++) {
+if (def->sounds[i]->info.type !=
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI)
+continue;
+idx = def->sounds[i]->info.addr.pci.bus;
+if (virDomainDefMaybeAddController(def,
+
VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE,
+ idx) < 0)
+return -1;
+}
+
+for (i = 0; i < def->nvideos; i++) {
+if (def->videos[i]->info.type !=
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI)
+continue;
+idx = def->videos[i]->info.addr.pci.bus;
+if (virDomainDefMaybeAddController(def,
+
VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE,
+ idx) < 0)
+return -1;
+}
+
+if (def->watchdog->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI)
+idx = def->watchdog->info.addr.pci.bus;
+
+if (virDomainDefMaybeAddController(def,
+
VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE,
+ idx) < 0)
+return -1;
+
+if (def->memballoon->info.type !=
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI)
+idx = def->memballoon->info.addr.pci.bus;
+
+if (virDomainDefMaybeAddController(def,
+
VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE,
+ idx) < 0)
+return -1;
+
+return 0;
+}
+
/*
* Based on the declared info for any devices,
* add necessary drive controllers which are not already present
@@ -11790,6 +11844,9 @@ int
virDomainDefAddImplicitControllers(virDomainDefPtr def)
if (virDomainDefMaybeAddSmartcardController(def) < 0)
return -1;
+if (virDomainDefMaybeAddPcibridgeController(def) < 0)
+return -1;
+
return 0;
}
--
regards!
li guang
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 2/3] build command line for pci-bridge device of qemu
在 2013-01-15二的 09:27 +，Daniel P. Berrange写道：
> On Mon, Jan 14, 2013 at 05:23:54PM +0100, Ján Tomko wrote:
> > On 01/10/13 02:04, liguang wrote:
> > > diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
> > > index 04a9512..48b4f46 100644
> > > --- a/src/qemu/qemu_command.c
> > > +++ b/src/qemu/qemu_command.c
> > > @@ -966,13 +966,6 @@ static char
> > > *qemuPCIAddressAsString(virDomainDeviceInfoPtr dev)
> > > {
> > > char *addr;
> > >
> > > -if (dev->addr.pci.domain != 0 ||
> > > -dev->addr.pci.bus != 0) {
> > > -virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> > > - _("Only PCI domain 0 and bus 0 are available"));
> > > -return NULL;
> > > -}
> > > -
> > > if (virAsprintf(&addr, "%d:%d:%d.%d",
> > > dev->addr.pci.domain,
> > > dev->addr.pci.bus,
> > > @@ -984,8 +977,24 @@ static char
> > > *qemuPCIAddressAsString(virDomainDeviceInfoPtr dev)
> > > return addr;
> > > }
> > >
> > > +static int qemuPciBridgeSupport(virDomainDefPtr def)
> > > +{
> > > +int i, c = 0;
> > > +
> > > +for (i = 0; i < def->ncontrollers; i++) {
> > > +virDomainControllerDefPtr controller = def->controllers[i];
> > > +
> > > +if (controller->type == VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE)
> > > +c++;
> > > +}
> > >
> > > -static int qemuCollectPCIAddress(virDomainDefPtr def ATTRIBUTE_UNUSED,
> > > +if (c > 1)
> > > +return 0;
> > > +else
> > > +return -1;
> > > +}
> > > +
> > > +static int qemuCollectPCIAddress(virDomainDefPtr def,
> > > virDomainDeviceDefPtr device,
> > > virDomainDeviceInfoPtr info,
> > > void *opaque)
> > > @@ -1004,6 +1013,20 @@ static int qemuCollectPCIAddress(virDomainDefPtr
> > > def ATTRIBUTE_UNUSED,
> > > return 0;
> > > }
> > >
> > > +if (info->addr.pci.domain != 0) {
> > > +virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> > > + _("Only PCI device addresses with "
> > > + "domain=0 are supported"));
> > > +return -1;
> > > +}
> > > +
> > > +if (info->addr.pci.bus != 0 && qemuPciBridgeSupport(def) < 0) {
> > > +virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> > > + _("Only PCI device addresses with bus=0 are"
> > > + " supported without pci-bridge support"));
> > > + return -1;
> > > +}
> > > +
> >
> > This would allow any bus number, even if we don't have enough PCI
> > bridges. It is also not the only place where qemuPCIAddressAsString is
> > called from and where this needs to be checked.
>
> With other types of addresses, we will auto-create the
> elements if we find the controller does not exist. We should probably
> do the same for PCI. ie if you have bus == 2 and no PCI bridge for
> that bus exists, then add one.
Oh, this amazing feature will remove all the need of
controller pre-definition in domain's XML file, will it?
could you please give me an already exist example?
just can't find them by a quick search.
Thanks!
>
> Daniel
--
regards!
li guang
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 2/3] build command line for pci-bridge device of qemu
在 2013-01-14一的 17:23 +0100，Ján Tomko写道：
> On 01/10/13 02:04, liguang wrote:
> > diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
> > index 04a9512..48b4f46 100644
> > --- a/src/qemu/qemu_command.c
> > +++ b/src/qemu/qemu_command.c
> > @@ -966,13 +966,6 @@ static char
> > *qemuPCIAddressAsString(virDomainDeviceInfoPtr dev)
> > {
> > char *addr;
> >
> > -if (dev->addr.pci.domain != 0 ||
> > -dev->addr.pci.bus != 0) {
> > -virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> > - _("Only PCI domain 0 and bus 0 are available"));
> > -return NULL;
> > -}
> > -
> > if (virAsprintf(&addr, "%d:%d:%d.%d",
> > dev->addr.pci.domain,
> > dev->addr.pci.bus,
> > @@ -984,8 +977,24 @@ static char
> > *qemuPCIAddressAsString(virDomainDeviceInfoPtr dev)
> > return addr;
> > }
> >
> > +static int qemuPciBridgeSupport(virDomainDefPtr def)
> > +{
> > +int i, c = 0;
> > +
> > +for (i = 0; i < def->ncontrollers; i++) {
> > +virDomainControllerDefPtr controller = def->controllers[i];
> > +
> > +if (controller->type == VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE)
> > +c++;
> > +}
> >
> > -static int qemuCollectPCIAddress(virDomainDefPtr def ATTRIBUTE_UNUSED,
> > +if (c > 1)
> > +return 0;
> > +else
> > +return -1;
> > +}
> > +
> > +static int qemuCollectPCIAddress(virDomainDefPtr def,
> > virDomainDeviceDefPtr device,
> > virDomainDeviceInfoPtr info,
> > void *opaque)
> > @@ -1004,6 +1013,20 @@ static int qemuCollectPCIAddress(virDomainDefPtr def
> > ATTRIBUTE_UNUSED,
> > return 0;
> > }
> >
> > +if (info->addr.pci.domain != 0) {
> > +virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> > + _("Only PCI device addresses with "
> > + "domain=0 are supported"));
> > +return -1;
> > +}
> > +
> > +if (info->addr.pci.bus != 0 && qemuPciBridgeSupport(def) < 0) {
> > +virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> > + _("Only PCI device addresses with bus=0 are"
> > + " supported without pci-bridge support"));
> > +return -1;
> > +}
> > +
>
> This would allow any bus number, even if we don't have enough PCI
> bridges.
maybe, but who tell us the pci bus number limitation?
if I know the limitation I will limit it.
> It is also not the only place where qemuPCIAddressAsString is
> called from and where this needs to be checked.
> We also have other functions assuming bus = 0.
> qemuDomainPCIAddressGetNextSlot should also take the bridges into
> account, for devices without a specified address.
Yes, but I removed others, for they are unnecessary.
>
> I'll try to post patches dealing with that sometime later this week.
> Jan
--
regards!
li guang
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 0/3] add pci-bridge support
ping ... 在 2013-01-10四的 09:04 +0800，liguang写道： > Now, it's impossible to arrange devices into multi-pci-bus, > for example: > >function='0x0'/> > > > >function='0x0'/> > > libvirt will complain about "bus != 0", > fortunately, qemu supports pci-to-pci bridge, > if we want to use multi-pci-bus, we can define > 2 pci bridge controllers, then attach 1 to the other > as a subordinate pci-bus, so, 2 pci-buses appear. > for example: > > >function='0x0'/> > > >function='0x0'/> > > > >function='0x0'/> > > > > src/conf/domain_conf.c|5 - > src/conf/domain_conf.h|1 + > docs/schemas/domaincommon.rng |1 + > src/qemu/qemu_capabilities.c |2 + > src/qemu/qemu_capabilities.h |1 + > src/qemu/qemu_command.c | 70 - > 6 files changed, 57 insertions(+), 23 deletions(-) -- regards! li guang -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/2] add qemu machine type q35 support
在 2013-01-09三的 21:24 -0500，Laine Stump写道： > On 01/08/2013 10:15 PM, Doug Goldstein wrote: > > On Tue, Jan 8, 2013 at 8:35 PM, liguang wrote: > >> qemu-1.3 added machine type q35, > >> changelog said: > >> Added Intel Q35 chipset as a new machine type, > >> '--machine q35'. Adds PCIe support. Requires an updated SeaBIOS (bios.bin), > >> and '-acpitable file=/seabios-path/q35-acpi-dsdt.aml' to run. > >> so add q35 support for libvirt. > >> > >> src/conf/device_conf.c |8 +++- > >> src/conf/device_conf.h |1 + > >> src/conf/domain_conf.c |1 + > >> src/conf/domain_conf.h |1 + > >> src/qemu/qemu_capabilities.c | 11 +++ > >> src/qemu/qemu_capabilities.h |1 + > >> src/qemu/qemu_command.c |8 +++- > >> 7 files changed, 29 insertions(+), 2 deletions(-) > >> > > I'd personally NACK this series for the time being. Per the qemu > > maintainers, q35 isn't really fully ready until 1.4. They're actively > > in the process of hashing out the machine type which will be exposed > > on the command line and via QMP so I think we really need to wait > > until that lands in upstream's repo before we add code for it in > > libvirt. > > In addition there is the issue that libvirt currently makes assumptions > about the bus topology of guests, and assigns pci addresses to guest > devices accordingly. Beyond the basic layout of buses present on the > machine, certain addresses are reserved/used for certain default devices > (e.g. the first video device). The q35 machine type will have a > different topology, so the default addresses of these basic devices may > (will? haven't looked at the details yet) change, and different > addresses will be available for assigning to additional guest pci > devices. (This assumption was actually already a problem, because > libvirt currently incorrectly assumes the default addresses and bus > layout even for non-x86 machinetypes.) > > To properly solve this problem, libvirt will need a method of learning > the topology and default device address assignment for each machine type > during capabilities discovery, and honor that information (rather than > just making decisions based on assumptions) during guest device assignment. > > I'm already working with someone from qemu on a design and patches to > implement this functionality, so to avoid duplication of effort, you > should wait to see what that looks like before you do any more work in > this area. (A colleague has also been working on PCI bridge support, > which has the potential to conflict with the PCI-e/q35 work if not done > in a coordinated fashion, so you may want to take a wait-and-see > approach there as well.) > glad to hear that, I've committed some patches to support pci-bridge, https://www.redhat.com/archives/libvir-list/2013-January/msg00577.html > -- > libvir-list mailing list > libvir-list@redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list -- regards! li guang -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/2] add qemu pci-express device support
在 2013-01-09三的 10:32 +，Daniel P. Berrange写道：
> On Wed, Jan 09, 2013 at 10:35:32AM +0800, liguang wrote:
> > Signed-off-by: liguang
> > ---
> > src/conf/device_conf.c |8 +++-
> > src/conf/device_conf.h |1 +
> > src/qemu/qemu_capabilities.c | 11 +++
> > src/qemu/qemu_capabilities.h |1 +
> > src/qemu/qemu_command.c |4 +++-
> > 5 files changed, 23 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/conf/device_conf.c b/src/conf/device_conf.c
> > index 7b97f45..3fca853 100644
> > --- a/src/conf/device_conf.c
> > +++ b/src/conf/device_conf.c
> > @@ -51,7 +51,7 @@ int
> > virDevicePCIAddressParseXML(xmlNodePtr node,
> > virDevicePCIAddressPtr addr)
> > {
> > -char *domain, *slot, *bus, *function, *multi;
> > +char *domain, *slot, *bus, *function, *multi, *expr;
> > int ret = -1;
> >
> > memset(addr, 0, sizeof(*addr));
> > @@ -61,6 +61,7 @@ virDevicePCIAddressParseXML(xmlNodePtr node,
> > slot = virXMLPropString(node, "slot");
> > function = virXMLPropString(node, "function");
> > multi= virXMLPropString(node, "multifunction");
> > +expr = virXMLPropString(node, "express");
>
> NACK, this is a gross hack.
>
> The q35 machine type provides multiple PCI buses, and it is
> already possible to express connection to the alternative
> buses using the 'bus' parameter. We don't need a new 'express'
> parameter. We need to make sure that the XML includes a
> element for each PCI bus provided by a machine
> type
>
> Daniel
OK, will drop this unnecessary patch.
--
regards!
li guang
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/2] build acpitable argument for qemu
在 2013-01-09三的 10:23 -0500，Cole Robinson写道：
> On 01/09/2013 05:31 AM, Daniel P. Berrange wrote:
> > On Wed, Jan 09, 2013 at 10:35:33AM +0800, liguang wrote:
> >> Signed-off-by: liguang
> >> ---
> >> src/conf/domain_conf.c |1 +
> >> src/conf/domain_conf.h |1 +
> >> src/qemu/qemu_command.c |4
> >> 3 files changed, 6 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
> >> index 6a7646e..54ba77f 100644
> >> --- a/src/conf/domain_conf.c
> >> +++ b/src/conf/domain_conf.c
> >> @@ -9548,6 +9548,7 @@ static virDomainDefPtr
> >> virDomainDefParseXML(virCapsPtr caps,
> >>
> >> def->os.bootloader = virXPathString("string(./bootloader)", ctxt);
> >> def->os.bootloaderArgs = virXPathString("string(./bootloader_args)",
> >> ctxt);
> >> +def->os.acpitable = virXPathString("string(./bootloader_args)", ctxt);
> >>
> >
> > This is clearly bogus - you can't just grab an existing XML field and
> > repurpose it. Second we shouldn't be requireing the user to specify
> > custom ACPI tables just to use the machine type. libvirt should do the
> > right thing with q35.
> >
> > Daniel
> >
>
> Also, there are patches on qemu-devel which claim to remove the -acpitable
> requirement.
>
> https://lists.gnu.org/archive/html/qemu-devel/2013-01/msg00356.html
>
> - Cole
Thanks!
--
regards!
li guang
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 1/2] add pci-bridge controller type
在 2013-01-08二的 08:04 +，Daniel P. Berrange写道：
> On Tue, Jan 08, 2013 at 09:58:49AM +0800, liguang wrote:
> > Signed-off-by: liguang
> > ---
> > src/conf/device_conf.c | 12 +++-
> > src/conf/device_conf.h |1 +
> > src/conf/domain_conf.c |5 -
> > src/conf/domain_conf.h |1 +
> > 4 files changed, 17 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/conf/device_conf.c b/src/conf/device_conf.c
> > index 7b97f45..1c06ed0 100644
> > --- a/src/conf/device_conf.c
> > +++ b/src/conf/device_conf.c
> > @@ -51,16 +51,18 @@ int
> > virDevicePCIAddressParseXML(xmlNodePtr node,
> > virDevicePCIAddressPtr addr)
> > {
> > -char *domain, *slot, *bus, *function, *multi;
> > +char *domain, *slot, *bus, *function, *multi, *bridge;
> > int ret = -1;
> >
> > memset(addr, 0, sizeof(*addr));
> > +addr->bridge = -1;
> >
> > domain = virXMLPropString(node, "domain");
> > bus = virXMLPropString(node, "bus");
> > slot = virXMLPropString(node, "slot");
> > function = virXMLPropString(node, "function");
> > multi= virXMLPropString(node, "multifunction");
> > +bridge = virXMLPropString(node, "bridge");
> >
> > if (domain &&
> > virStrToLong_ui(domain, NULL, 0, &addr->domain) < 0) {
> > @@ -98,6 +100,14 @@ virDevicePCIAddressParseXML(xmlNodePtr node,
> > goto cleanup;
> >
> > }
> > +
> > +if (bridge &&
> > +virStrToLong_i(bridge, NULL, 0, &addr->bridge) < 0) {
> > +virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> > + _("pci-bridge number must be >= 0 "));
> > +goto cleanup;
> > +}
>
> This is bogus - there's no need for a new 'bridge' attribute - we
> have 'bus' which is sufficient.
Oh, yes, this version 'bridge' is unnecessary.
In former version, I want to discriminate if a pci device want to
sitting on default bus pci.0 or pci-bridge0, so bring in 'bridge'.
Thanks!
>
>
> Daniel
--
regards!
li guang
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 1/2] add pci-bridge controller type
在 2013-01-08二的 08:51 +，Daniel P. Berrange写道：
> On Tue, Jan 08, 2013 at 04:47:40PM +0800, li guang wrote:
> > 在 2013-01-08二的 16:37 +0800，li guang写道：
> > > 在 2013-01-08二的 08:04 +，Daniel P. Berrange写道：
> > > > On Tue, Jan 08, 2013 at 09:58:49AM +0800, liguang wrote:
> > > > > Signed-off-by: liguang
> > > > > ---
> > > > > src/conf/device_conf.c | 12 +++-
> > > > > src/conf/device_conf.h |1 +
> > > > > src/conf/domain_conf.c |5 -
> > > > > src/conf/domain_conf.h |1 +
> > > > > 4 files changed, 17 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/src/conf/device_conf.c b/src/conf/device_conf.c
> > > > > index 7b97f45..1c06ed0 100644
> > > > > --- a/src/conf/device_conf.c
> > > > > +++ b/src/conf/device_conf.c
> > > > > @@ -51,16 +51,18 @@ int
> > > > > virDevicePCIAddressParseXML(xmlNodePtr node,
> > > > > virDevicePCIAddressPtr addr)
> > > > > {
> > > > > -char *domain, *slot, *bus, *function, *multi;
> > > > > +char *domain, *slot, *bus, *function, *multi, *bridge;
> > > > > int ret = -1;
> > > > >
> > > > > memset(addr, 0, sizeof(*addr));
> > > > > +addr->bridge = -1;
> > > > >
> > > > > domain = virXMLPropString(node, "domain");
> > > > > bus = virXMLPropString(node, "bus");
> > > > > slot = virXMLPropString(node, "slot");
> > > > > function = virXMLPropString(node, "function");
> > > > > multi= virXMLPropString(node, "multifunction");
> > > > > +bridge = virXMLPropString(node, "bridge");
> > > > >
> > > > > if (domain &&
> > > > > virStrToLong_ui(domain, NULL, 0, &addr->domain) < 0) {
> > > > > @@ -98,6 +100,14 @@ virDevicePCIAddressParseXML(xmlNodePtr node,
> > > > > goto cleanup;
> > > > >
> > > > > }
> > > > > +
> > > > > +if (bridge &&
> > > > > +virStrToLong_i(bridge, NULL, 0, &addr->bridge) < 0) {
> > > > > +virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> > > > > + _("pci-bridge number must be >= 0 "));
> > > > > +goto cleanup;
> > > > > +}
> > > >
> > > > This is bogus - there's no need for a new 'bridge' attribute - we
> > > > have 'bus' which is sufficient.
> > >
> > > Oh, yes, this version 'bridge' is unnecessary.
> > >
> > > In former version, I want to discriminate if a pci device want to
> > > sitting on default bus pci.0 or pci-bridge0, so bring in 'bridge'.
> > >
> > > Thanks!
> >
> > but, without 'bridge', can't know if user want or don't want pci-bridge,
> > and the check for 'bus != 0' will be removed, then if user happened to
> > define a pci device greater than 0, qemu will complain about this,
> > so it's inconvenient for this case.
>
> The check for 'bus != 0' was only added because we didn't have any
> support for bridges. Once we have bridge support, then that check
> can be changed. If bus != 0, then check to see if there's a matching
> bridge device, otherwise raise an error.
OK for me, though it seems much more changes will be involved
than with 'bridge' condition.
>
> Daniel
--
regards!
li guang
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 1/2] add pci-bridge controller type
在 2013-01-08二的 16:37 +0800，li guang写道：
> 在 2013-01-08二的 08:04 +，Daniel P. Berrange写道：
> > On Tue, Jan 08, 2013 at 09:58:49AM +0800, liguang wrote:
> > > Signed-off-by: liguang
> > > ---
> > > src/conf/device_conf.c | 12 +++-
> > > src/conf/device_conf.h |1 +
> > > src/conf/domain_conf.c |5 -
> > > src/conf/domain_conf.h |1 +
> > > 4 files changed, 17 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/src/conf/device_conf.c b/src/conf/device_conf.c
> > > index 7b97f45..1c06ed0 100644
> > > --- a/src/conf/device_conf.c
> > > +++ b/src/conf/device_conf.c
> > > @@ -51,16 +51,18 @@ int
> > > virDevicePCIAddressParseXML(xmlNodePtr node,
> > > virDevicePCIAddressPtr addr)
> > > {
> > > -char *domain, *slot, *bus, *function, *multi;
> > > +char *domain, *slot, *bus, *function, *multi, *bridge;
> > > int ret = -1;
> > >
> > > memset(addr, 0, sizeof(*addr));
> > > +addr->bridge = -1;
> > >
> > > domain = virXMLPropString(node, "domain");
> > > bus = virXMLPropString(node, "bus");
> > > slot = virXMLPropString(node, "slot");
> > > function = virXMLPropString(node, "function");
> > > multi= virXMLPropString(node, "multifunction");
> > > +bridge = virXMLPropString(node, "bridge");
> > >
> > > if (domain &&
> > > virStrToLong_ui(domain, NULL, 0, &addr->domain) < 0) {
> > > @@ -98,6 +100,14 @@ virDevicePCIAddressParseXML(xmlNodePtr node,
> > > goto cleanup;
> > >
> > > }
> > > +
> > > +if (bridge &&
> > > +virStrToLong_i(bridge, NULL, 0, &addr->bridge) < 0) {
> > > +virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> > > + _("pci-bridge number must be >= 0 "));
> > > +goto cleanup;
> > > +}
> >
> > This is bogus - there's no need for a new 'bridge' attribute - we
> > have 'bus' which is sufficient.
>
> Oh, yes, this version 'bridge' is unnecessary.
>
> In former version, I want to discriminate if a pci device want to
> sitting on default bus pci.0 or pci-bridge0, so bring in 'bridge'.
>
> Thanks!
but, without 'bridge', can't know if user want or don't want pci-bridge,
and the check for 'bus != 0' will be removed, then if user happened to
define a pci device greater than 0, qemu will complain about this,
so it's inconvenient for this case.
>
> >
> >
> > Daniel
>
--
regards!
li guang
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v2 0/2] add pci-bridge support
在 2013-01-07一的 22:44 -0600，Doug Goldstein写道： > On Mon, Jan 7, 2013 at 7:58 PM, liguang wrote: > > Now, it's impossible to arrange devices into multi-pci-bus, > > for example: > > > >> function='0x0'/> > > > > > > > >> function='0x0'/> > > > > libvirt will complain about "bus != 0", > > fortunately, qemu supports pci-to-pci bridge, > > if we want to use multi-pci-bus, we can define > > 2 pci bridge controllers, then attach 1 to the other > > as a subordinate pci-bus, so, 2 pci-buses appear. > > for example: > > > > > >> function='0x0' bridge='0'/> > > > > > >> function='0x0' bridge='1'/> > > > > > > > >> function='0x0' bridge='0'/> > > > > > > > > src/conf/device_conf.c | 11 ++- > > src/conf/device_conf.h |1 + > > src/conf/domain_conf.c |5 - > > src/conf/domain_conf.h |1 + > > src/qemu/qemu_command.c | 25 - > > 5 files changed, 36 insertions(+), 7 deletions(-) > > > > I had a few comments to the specific patches. I think you're missing > one part to the whole series which should probably be 1/3 in the patch > series. Adding a QEMU_CAP for PCI Bridge support and specifically > probing it or adding it where it was supported. Since we're modifying > the QEMU command line arguments this series probably needs to add some > test cases as well. > OK, thanks! -- regards! li guang -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v2 2/2] build command line for pci-bridge device of qemu
在 2013-01-07一的 22:42 -0600，Doug Goldstein写道：
> On Mon, Jan 7, 2013 at 7:58 PM, liguang wrote:
> > Signed-off-by: liguang
> > ---
> > src/qemu/qemu_command.c | 25 -
> > 1 files changed, 20 insertions(+), 5 deletions(-)
> >
> > diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
> > index 04a9512..0da32e0 100644
> > --- a/src/qemu/qemu_command.c
> > +++ b/src/qemu/qemu_command.c
> > @@ -966,10 +966,15 @@ static char
> > *qemuPCIAddressAsString(virDomainDeviceInfoPtr dev)
> > {
> > char *addr;
> >
> > -if (dev->addr.pci.domain != 0 ||
> > -dev->addr.pci.bus != 0) {
> > +if (dev->addr.pci.domain != 0) {
> > virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> > - _("Only PCI domain 0 and bus 0 are available"));
> > + _("Only PCI domain 0 is available"));
> > +return NULL;
> > +}
> > +if (dev->addr.pci.bridge < 0 && dev->addr.pci.bus != 0) {
> > +virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> > + _("Only PCI bus 0 is available "
> > + "without pci-bridge support"));
> > return NULL;
> > }
> >
> > @@ -1768,7 +1773,7 @@ qemuBuildDeviceAddressStr(virBufferPtr buf,
> > _("Only PCI device addresses with domain=0 are
> > supported"));
> > return -1;
> > }
> > -if (info->addr.pci.bus != 0) {
> > +if (info->addr.pci.bus != 0 && info->addr.pci.bridge < 0) {
> > virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> > _("Only PCI device addresses with bus=0 are
> > supported"));
>
> Above you added the qualifier "without pci-bridge support" to the
> error message. Probably worth being consistent and adding it here as
> well.
>
OK, will fix.
> > return -1;
> > @@ -1801,7 +1806,9 @@ qemuBuildDeviceAddressStr(virBufferPtr buf,
> > * When QEMU grows support for > 1 PCI domain, then pci.0 change
> > * to pciNN.0 where NN is the domain number
> > */
> > -if (qemuCapsGet(caps, QEMU_CAPS_PCI_MULTIBUS))
> > +if (info->addr.pci.bridge >= 0)
> > +virBufferAsprintf(buf, ",bus=pci.%d", info->addr.pci.bus);
> > +else if (qemuCapsGet(caps, QEMU_CAPS_PCI_MULTIBUS))
> > virBufferAsprintf(buf, ",bus=pci.0");
> > else
> > virBufferAsprintf(buf, ",bus=pci");
> > @@ -3064,6 +3071,12 @@ qemuBuildControllerDevStr(virDomainDefPtr domainDef,
> > int model;
> >
> > switch (def->type) {
> > +case VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE:
> > +virBufferAsprintf(&buf, "pci-bridge,chassis_nr=%d", def->idx+1);
> > +virBufferAsprintf(&buf, ",id=pci.%d", def->idx);
> > +if (def->idx == 0)
> > +goto out;
> > +break;
> > case VIR_DOMAIN_CONTROLLER_TYPE_SCSI:
> > model = def->model;
> > if ((qemuSetScsiControllerModel(domainDef, caps, &model)) < 0)
> > @@ -3137,6 +3150,7 @@ qemuBuildControllerDevStr(virDomainDefPtr domainDef,
> > if (qemuBuildDeviceAddressStr(&buf, &def->info, caps) < 0)
> > goto error;
> >
> > +out:
> > if (virBufferError(&buf)) {
> > virReportOOMError();
> > goto error;
> > @@ -5033,6 +5047,7 @@ qemuBuildCommandLine(virConnectPtr conn,
> > /* We don't add an explicit IDE or FD controller because the
> > * provided PIIX4 device already includes one. It isn't possible to
> > * remove the PIIX4. */
> > +VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE,
> > VIR_DOMAIN_CONTROLLER_TYPE_USB,
> > VIR_DOMAIN_CONTROLLER_TYPE_SCSI,
> > VIR_DOMAIN_CONTROLLER_TYPE_SATA,
> > --
> > 1.7.2.5
> >
> >
>
--
regards!
li guang
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v2 1/2] add pci-bridge controller type
在 2013-01-07一的 22:38 -0600，Doug Goldstein写道：
> On Mon, Jan 7, 2013 at 7:58 PM, liguang wrote:
> > Signed-off-by: liguang
> > ---
> > src/conf/device_conf.c | 12 +++-
> > src/conf/device_conf.h |1 +
> > src/conf/domain_conf.c |5 -
> > src/conf/domain_conf.h |1 +
> > 4 files changed, 17 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/conf/device_conf.c b/src/conf/device_conf.c
> > index 7b97f45..1c06ed0 100644
> > --- a/src/conf/device_conf.c
> > +++ b/src/conf/device_conf.c
> > @@ -51,16 +51,18 @@ int
> > virDevicePCIAddressParseXML(xmlNodePtr node,
> > virDevicePCIAddressPtr addr)
> > {
> > -char *domain, *slot, *bus, *function, *multi;
> > +char *domain, *slot, *bus, *function, *multi, *bridge;
> > int ret = -1;
> >
> > memset(addr, 0, sizeof(*addr));
> > +addr->bridge = -1;
> >
> > domain = virXMLPropString(node, "domain");
> > bus = virXMLPropString(node, "bus");
> > slot = virXMLPropString(node, "slot");
> > function = virXMLPropString(node, "function");
> > multi= virXMLPropString(node, "multifunction");
> > +bridge = virXMLPropString(node, "bridge");
> >
> > if (domain &&
> > virStrToLong_ui(domain, NULL, 0, &addr->domain) < 0) {
> > @@ -98,6 +100,14 @@ virDevicePCIAddressParseXML(xmlNodePtr node,
> > goto cleanup;
> >
> > }
> > +
> > +if (bridge &&
> > +virStrToLong_i(bridge, NULL, 0, &addr->bridge) < 0) {
> > +virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> > + _("pci-bridge number must be >= 0 "));
> > +goto cleanup;
> > +}
>
> This check isn't correct for the error message. The check is saying
> that we weren't able to parse out the value specified (look at the
> checks earlier in the function). The subsequent checks (where this
> code is added) checks for the validity of the values and use
> VIR_ERR_CONFIG_UNSUPPORTED.
>
No
> You're also failing to free bridge in the cleanup section.
Yes, will fix.
>
> > +
> > if (!virDevicePCIAddressIsValid(addr)) {
> > virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> > _("Insufficient specification for PCI address"));
> > diff --git a/src/conf/device_conf.h b/src/conf/device_conf.h
> > index 5318738..7ac3461 100644
> > --- a/src/conf/device_conf.h
> > +++ b/src/conf/device_conf.h
> > @@ -48,6 +48,7 @@ struct _virDevicePCIAddress {
> > unsigned int slot;
> > unsigned int function;
> > int multi; /* enum virDomainDeviceAddressPciMulti */
> > +int bridge; /* for pci-bridge */
> > };
> >
> > int virDevicePCIAddressIsValid(virDevicePCIAddressPtr addr);
> > diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
> > index 6a7646e..8ebe77d 100644
> > --- a/src/conf/domain_conf.c
> > +++ b/src/conf/domain_conf.c
> > @@ -264,7 +264,8 @@ VIR_ENUM_IMPL(virDomainController,
> > VIR_DOMAIN_CONTROLLER_TYPE_LAST,
> >"sata",
> >"virtio-serial",
> >"ccid",
> > - "usb")
> > + "usb",
> > + "pci-bridge")
> >
> > VIR_ENUM_IMPL(virDomainControllerModelSCSI,
> > VIR_DOMAIN_CONTROLLER_MODEL_SCSI_LAST,
> >"auto",
> > @@ -4479,6 +4480,8 @@ virDomainControllerDefParseXML(xmlNodePtr node,
> > goto error;
> >
> > switch (def->type) {
> > +case VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE:
> > +break;
> > case VIR_DOMAIN_CONTROLLER_TYPE_VIRTIO_SERIAL: {
> > char *ports = virXMLPropString(node, "ports");
> > if (ports) {
> > diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
> > index 5062e07..56e5a40 100644
> > --- a/src/conf/domain_conf.h
> > +++ b/src/conf/domain_conf.h
> > @@ -652,6 +652,7 @@ enum virDomainControllerType {
> > VIR_DOMAIN_CONTROLLER_TYPE_VIRTIO_SERIAL,
> > VIR_DOMAIN_CONTROLLER_TYPE_CCID,
> > VIR_DOMAIN_CONTROLLER_TYPE_USB,
> > +VIR_DOMAIN_CONTROLLER_TYPE_PCIBRIDGE,
> >
> > VIR_DOMAIN_CONTROLLER_TYPE_LAST
> > };
> > --
> > 1.7.2.5
> >
> >
>
> Looks like:
>
> int virDevicePCIAddressIsValid(virDevicePCIAddressPtr addr)
>
> Needs to be updated as well part of this series to allow bus to not be
> 0 anymore.
>
> This change also needs an update to the XML schemas in
> docs/schemas/basictypes.rng
>
--
regards!
li guang
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/3] add pci-brige device command line for qemu
在 2013-01-07一的 17:57 +0100，Ján Tomko写道：
> On 01/04/13 03:28, li guang wrote:
> > 在 2013-01-03四的 16:13 +0100，Ján Tomko写道：
> >> On 12/26/12 02:00, liguang wrote:
> >>> @@ -1801,10 +1803,13 @@ qemuBuildDeviceAddressStr(virBufferPtr buf,
> >>> * When QEMU grows support for > 1 PCI domain, then pci.0 change
> >>> * to pciNN.0 where NN is the domain number
> >>> */
> >>> -if (qemuCapsGet(caps, QEMU_CAPS_PCI_MULTIBUS))
> >>> +if (info->type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCIBRIDGE) {
> >>> +virBufferAsprintf(buf, ",bus=pci-bridge%d",
> >>> info->addr.pci.bus);
> >>> +} else if (qemuCapsGet(caps, QEMU_CAPS_PCI_MULTIBUS)) {
> >>> virBufferAsprintf(buf, ",bus=pci.0");
> >>
> >> Is there any way (or plan) to use more pci buses with QEMU other than
> >> with the pci bridges? If not, we could just name the bridges pci.%d. (If
> >> we index the bridges from 1).
> >
> > as far as I know, qemu can't use multi-pci-bus,
> > so only pci.0 accepted now.
> >
> >>
> >>> -else
> >>> +} else {
> >>> virBufferAsprintf(buf, ",bus=pci");
> >>> +}
> >>> if (info->addr.pci.multi == VIR_DEVICE_ADDRESS_PCI_MULTI_ON)
> >>> virBufferAddLit(buf, ",multifunction=on");
> >>> else if (info->addr.pci.multi ==
> >>> VIR_DEVICE_ADDRESS_PCI_MULTI_OFF)
> >>> @@ -3455,6 +3460,32 @@ error:
> >>> return NULL;
> >>> }
> >>
> >>
> >>>
> >>> +char *
> >>> +qemuBuildPCIbridgeDevStr(virDomainPCIbridgeDefPtr dev,
> >>> + qemuCapsPtr caps, int idx)
> >>> +{
> >>> +virBuffer buf = VIR_BUFFER_INITIALIZER;
> >>> +
> >>> +virBufferAsprintf(&buf, "pci-bridge,chassis_nr=1");
> >>
> >> The chassis number has to be unique for each bridge.
> >
> > chassis number is not so important,
> > here, I just set all bridges in same chassis.
> >
>
>
> > Each bridge must have a unique chassis #.
> > You *must* set it to a value > 0.
> > I don't check that it is unique, just that it is >0.
> > If you make it non unique, guest will be confused.
>
> http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg02765.html
Oh, to be a little pedantic, please refer to PCI-TO-PCI BRIDGE
ARCHITECTURE SPECIFICATION, REV 1.2, page 146, as I said before,
'I just set all bridges in same chassis', that means, 1 main chassis(#0)
,1 expansion chassis(#1), maybe it seems strange, but It's not illegal.
of course, I will consider your advice to make it unique.
Thanks!
>
> Jan
--
regards!
li guang
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/3] add pci-brige device command line for qemu
在 2013-01-03四的 16:13 +0100，Ján Tomko写道：
> On 12/26/12 02:00, liguang wrote:
> > @@ -1801,10 +1803,13 @@ qemuBuildDeviceAddressStr(virBufferPtr buf,
> > * When QEMU grows support for > 1 PCI domain, then pci.0 change
> > * to pciNN.0 where NN is the domain number
> > */
> > -if (qemuCapsGet(caps, QEMU_CAPS_PCI_MULTIBUS))
> > +if (info->type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCIBRIDGE) {
> > +virBufferAsprintf(buf, ",bus=pci-bridge%d",
> > info->addr.pci.bus);
> > +} else if (qemuCapsGet(caps, QEMU_CAPS_PCI_MULTIBUS)) {
> > virBufferAsprintf(buf, ",bus=pci.0");
>
> Is there any way (or plan) to use more pci buses with QEMU other than
> with the pci bridges? If not, we could just name the bridges pci.%d. (If
> we index the bridges from 1).
as far as I know, qemu can't use multi-pci-bus,
so only pci.0 accepted now.
>
> > -else
> > +} else {
> > virBufferAsprintf(buf, ",bus=pci");
> > +}
> > if (info->addr.pci.multi == VIR_DEVICE_ADDRESS_PCI_MULTI_ON)
> > virBufferAddLit(buf, ",multifunction=on");
> > else if (info->addr.pci.multi == VIR_DEVICE_ADDRESS_PCI_MULTI_OFF)
> > @@ -3455,6 +3460,32 @@ error:
> > return NULL;
> > }
>
>
> >
> > +char *
> > +qemuBuildPCIbridgeDevStr(virDomainPCIbridgeDefPtr dev,
> > + qemuCapsPtr caps, int idx)
> > +{
> > +virBuffer buf = VIR_BUFFER_INITIALIZER;
> > +
> > +virBufferAsprintf(&buf, "pci-bridge,chassis_nr=1");
>
> The chassis number has to be unique for each bridge.
chassis number is not so important,
here, I just set all bridges in same chassis.
>
> > +
> > +if ((dev->type != VIR_DOMAIN_PCIBRIDGE_TYPE_ROOT) &&
> > +(qemuBuildDeviceAddressStr(&buf, &dev->info, caps) < 0))
> > +goto error;
> > +else
> > + virBufferAsprintf(&buf, ",id=pci-bridge%d" , idx);
> > +
> > +if (virBufferError(&buf)) {
> > +virReportOOMError();
> > +goto error;
> > +}
> > +
> > +return virBufferContentAndReset(&buf);
> > +
> > +error:
> > +virBufferFreeAndReset(&buf);
> > +return NULL;
> > +
> > +}
>
--
regards!
li guang
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/3] add pci-bridge device and address type
在 2013-01-02三的 10:22 +，Daniel P. Berrange写道： > On Wed, Dec 26, 2012 at 09:00:06AM +0800, liguang wrote: > > Now, it's unnecessary to arrange devices into multi-pci-bus, > > for example: > > > >> function='0x0'/> > > > > > > > >> function='0x0'/> > > > > libvirt will complain about "bus != 0", > > fortunately, qemu supports pci-to-pci bridge, > > if we want to use multi-pci-bus, we can define > > 2 pci bridge devices then attach 1 to the other > > as a subordinate pci-bus, so, 2 pci-buses appear. > > for example: > > > > > >> function='0x0'/> > > > > > We shouldn't be introducing a new device for this. The > existing element is intended to handle all types of bus > devices. Just need to define a new controller type. okay, let me try to do it. > > Daniel -- regards! li guang -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/3] add pci-bridge device and address type
在 2012-12-27四的 08:47 +0800，li guang写道：
> 在 2012-12-26三的 18:07 +0800，Osier Yang写道：
>
> > >>
> > >> No, even it's not supported now, the proposed XML should be
> > >> designed compatible enough for future. Note that as long
> > >> as a new XML is added, it can't changed/removed for back-compact,
> > >> so when introducing new XMLs, you should consider the future.
> > >>
> > >> And on other hand, the introduced XML should be general
> > >> enough for all drivers, not only QEMU.
> > >>
> > >> Anyway, regardless of the current qemu implementation, I think
> > >> you should refer to the specification of PCI SGI, so that the
> > >> proposed XML could be compatible enough for the future.
> > >
> > > yes, I will, but any problem with the pci-bridge definition in XML?
> > > it's just a simple element.
> > > can you tell more details about problem of this new definition?
> >
> > The point is how to known the pci device is attached to which
> > pci bridge *if* multiple bridge is supported. I don't think
> > the two types ("root" and "subordinate") could do the work.
> >
>
> okay, let me describe the implicit map rule between bridge and device,
> before this, we should bear in mind 1 bridge corresponding to only 1 bus
>
> root bridge (bus 0)
>|
>- subordinate bridge (bus 1) (slot 0, bus 0)
>||
>|device 0 (slot 0, bus 1)
>||
>|device 1 (slot 1, bus 1)
>|
>-- device 0 (slot 2, bus 0)
>|
> ...
>
> this map rule was in embedded in my changes.
>
maybe I have to describe more detail about
the map rule between pci-bridge and devices,
demo XML:
will have following structure:
root bridge (bus 0)
|
-secondary bridge (bus 1) (bus 0, slot 0)
| |
| --subordinate bridge (bus 2) (bus 1, slot 0)
| | |
| | ---device 2 (bus 2, slot 0)
| |
| --device 1 (bus 1, slot 1)
|
-device 0 (bus 0, slot 1)
>
> > >
> > >>
> > >>> every subordinate will attach to root bridge, and has its own slot.
> > >>>
> > >>>>
> > >>>> To describe the relationship between bridges, perhaps we will need
> > >>>> "parent" and "child" properties for device.
> > >>>>
> > >>>> To describe the relatioship between a pci device and a pci bridge,
> > >>>> a property like "bridge" for general pci device should be enough.
> > >>>> In this case, another property for is needed, to
> > >>>> indentify it, such as "id" or "name".
> > >>>
> > >>> only relationship is not enough, it's unsuitable for passing '-device
> > >>> pci-bridge' to qemu, so I define a new device and address type for
> > >>> pci-bridge in libvirt.
> > >>>
> > >>>>
> > >>>> Regards,
> > >>>> Osier
> > >>>>
> > >>>>
> > >>>
> > >>
> > >
> >
>
--
regards!
li guang
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/3] add pci-bridge device and address type
在 2012-12-26三的 18:07 +0800，Osier Yang写道：
> >>
> >> No, even it's not supported now, the proposed XML should be
> >> designed compatible enough for future. Note that as long
> >> as a new XML is added, it can't changed/removed for back-compact,
> >> so when introducing new XMLs, you should consider the future.
> >>
> >> And on other hand, the introduced XML should be general
> >> enough for all drivers, not only QEMU.
> >>
> >> Anyway, regardless of the current qemu implementation, I think
> >> you should refer to the specification of PCI SGI, so that the
> >> proposed XML could be compatible enough for the future.
> >
> > yes, I will, but any problem with the pci-bridge definition in XML?
> > it's just a simple element.
> > can you tell more details about problem of this new definition?
>
> The point is how to known the pci device is attached to which
> pci bridge *if* multiple bridge is supported. I don't think
> the two types ("root" and "subordinate") could do the work.
>
okay, let me describe the implicit map rule between bridge and device,
before this, we should bear in mind 1 bridge corresponding to only 1 bus
root bridge (bus 0)
|
- subordinate bridge (bus 1) (slot 0, bus 0)
||
|device 0 (slot 0, bus 1)
||
|device 1 (slot 1, bus 1)
|
-- device 0 (slot 2, bus 0)
|
...
this map rule was in embedded in my changes.
> >
> >>
> >>> every subordinate will attach to root bridge, and has its own slot.
> >>>
> >>>>
> >>>> To describe the relationship between bridges, perhaps we will need
> >>>> "parent" and "child" properties for device.
> >>>>
> >>>> To describe the relatioship between a pci device and a pci bridge,
> >>>> a property like "bridge" for general pci device should be enough.
> >>>> In this case, another property for is needed, to
> >>>> indentify it, such as "id" or "name".
> >>>
> >>> only relationship is not enough, it's unsuitable for passing '-device
> >>> pci-bridge' to qemu, so I define a new device and address type for
> >>> pci-bridge in libvirt.
> >>>
> >>>>
> >>>> Regards,
> >>>> Osier
> >>>>
> >>>>
> >>>
> >>
> >
>
--
regards!
li guang
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/3] add pci-bridge device and address type
在 2012-12-26三的 16:28 +0800，Osier Yang写道： > On 2012年12月26日 16:12, li guang wrote: > > 在 2012-12-26三的 15:38 +0800，Osier Yang写道： > >> On 2012年12月26日 09:00, liguang wrote: > >>> Now, it's unnecessary to arrange devices into multi-pci-bus, > >>> for example: > >>> > >>> >>> function='0x0'/> > >>> > >>> > >>> > >>> >>> function='0x0'/> > >>> > >>> libvirt will complain about "bus != 0", > >>> fortunately, qemu supports pci-to-pci bridge, > >>> if we want to use multi-pci-bus, we can define > >>> 2 pci bridge devices then attach 1 to the other > >>> as a subordinate pci-bus, so, 2 pci-buses appear. > >>> for example: > >>> > >>> > >>> >>> function='0x0'/> > >>> > >>> > >>> >>> function='0x0'/> > >>> > >>> > >>> > >>> >>> function='0x0'/> > >>> > >> > >> I think this is rather not workable, E.g. how to known the video device > >> attached to which pci bridge if there are multiple pci bridges? > > > > please bear in mind bus 0 is root bridge, bus 1 is subordinate bridge, > > and so forth, which was implemented in my patch 2/3 > > That doesn't answer the question. video attached to root bridge(bus 0), slot 2 sound attached to bus 1 , slot 1 > > > > >> And the > >> new address type "pci-bridge" looks bogus, as the address properties of > >> a pci bridge are exactly same with a normal pci device. > >> > >> From the qemu patch: > >> > >> -device pci-bridge,id=bridge1 \ > >> -netdev user,id=u \ > >> -device ne2k_pci,id=net2,bus=bridge1,netdev=u > >> > >> I think what we only need is to describe the relapship between pci > >> bridge and pci bridge (if it's supported, the two types "root" and > >> "subordinate" are not enough to describe the relatioship), also pci > >> device and pci bridge. > > > > relationship between pci-bus and devices are embedded, just like > > pci.0, e.g. > > > function='0x0'/> > > means a device sitting on bus pci.0 slot 4 > > then after my changes > > > function='0x0'/> > > would have the same mean > > relationship between pci-bridges are primary and secondary, > > (as far as I know qemu doesn’t support multi-pci-bridges at present) > > so root and subordinate attribute may be enough, > > No, even it's not supported now, the proposed XML should be > designed compatible enough for future. Note that as long > as a new XML is added, it can't changed/removed for back-compact, > so when introducing new XMLs, you should consider the future. > > And on other hand, the introduced XML should be general > enough for all drivers, not only QEMU. > > Anyway, regardless of the current qemu implementation, I think > you should refer to the specification of PCI SGI, so that the > proposed XML could be compatible enough for the future. yes, I will, but any problem with the pci-bridge definition in XML? it's just a simple element. can you tell more details about problem of this new definition? > > > every subordinate will attach to root bridge, and has its own slot. > > > >> > >> To describe the relationship between bridges, perhaps we will need > >> "parent" and "child" properties for device. > >> > >> To describe the relatioship between a pci device and a pci bridge, > >> a property like "bridge" for general pci device should be enough. > >> In this case, another property for is needed, to > >> indentify it, such as "id" or "name". > > > > only relationship is not enough, it's unsuitable for passing '-device > > pci-bridge' to qemu, so I define a new device and address type for > > pci-bridge in libvirt. > > > >> > >> Regards, > >> Osier > >> > >> > > > -- regards! li guang -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/3] add pci-bridge device and address type
在 2012-12-26三的 15:38 +0800，Osier Yang写道： > On 2012年12月26日 09:00, liguang wrote: > > Now, it's unnecessary to arrange devices into multi-pci-bus, > > for example: > > > > > function='0x0'/> > > > > > > > > > function='0x0'/> > > > > libvirt will complain about "bus != 0", > > fortunately, qemu supports pci-to-pci bridge, > > if we want to use multi-pci-bus, we can define > > 2 pci bridge devices then attach 1 to the other > > as a subordinate pci-bus, so, 2 pci-buses appear. > > for example: > > > > > > > function='0x0'/> > > > > > > > function='0x0'/> > > > > > > > > > function='0x0'/> > > > > I think this is rather not workable, E.g. how to known the video device > attached to which pci bridge if there are multiple pci bridges? please bear in mind bus 0 is root bridge, bus 1 is subordinate bridge, and so forth, which was implemented in my patch 2/3 > And the > new address type "pci-bridge" looks bogus, as the address properties of > a pci bridge are exactly same with a normal pci device. > > From the qemu patch: > > -device pci-bridge,id=bridge1 \ > -netdev user,id=u \ > -device ne2k_pci,id=net2,bus=bridge1,netdev=u > > I think what we only need is to describe the relapship between pci > bridge and pci bridge (if it's supported, the two types "root" and > "subordinate" are not enough to describe the relatioship), also pci > device and pci bridge. relationship between pci-bus and devices are embedded, just like pci.0, e.g. means a device sitting on bus pci.0 slot 4 then after my changes would have the same mean relationship between pci-bridges are primary and secondary, (as far as I know qemu doesn’t support multi-pci-bridges at present) so root and subordinate attribute may be enough, every subordinate will attach to root bridge, and has its own slot. > > To describe the relationship between bridges, perhaps we will need > "parent" and "child" properties for device. > > To describe the relatioship between a pci device and a pci bridge, > a property like "bridge" for general pci device should be enough. > In this case, another property for is needed, to > indentify it, such as "id" or "name". only relationship is not enough, it's unsuitable for passing '-device pci-bridge' to qemu, so I define a new device and address type for pci-bridge in libvirt. > > Regards, > Osier > > -- regards! li guang -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2.1 04/11] qemu: Introduce nbd-server-add command
reviewed-by: liguang
在 2012-12-18二的 15:36 +0100，Michal Privoznik写道：
> This will be used with new migration scheme.
> This patch creates basically just monitor stub
> functions. Wiring them into something useful
> is done in later patches.
> ---
> src/qemu/qemu_monitor.c | 22 ++
> src/qemu/qemu_monitor.h | 3 +++
> src/qemu/qemu_monitor_json.c | 25 +
> src/qemu/qemu_monitor_json.h | 3 +++
> 4 files changed, 53 insertions(+)
>
> diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c
> index eab833f..0c848ee 100644
> --- a/src/qemu/qemu_monitor.c
> +++ b/src/qemu/qemu_monitor.c
> @@ -3342,3 +3342,25 @@ int qemuMonitorNBDServerStart(qemuMonitorPtr mon,
>
> return qemuMonitorJSONNBDServerStart(mon, host, port);
> }
> +
> +int qemuMonitorNBDServerAdd(qemuMonitorPtr mon,
> +const char *deviceID,
> +bool writable)
> +{
> +VIR_DEBUG("mon=%p deviceID=%s",
> + mon, deviceID);
> +
> +if (!mon) {
> +virReportError(VIR_ERR_INVALID_ARG, "%s",
> + _("monitor must not be NULL"));
> +return -1;
> +}
> +
> +if (!mon->json) {
> +virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
> + _("JSON monitor is required"));
> +return -1;
> +}
> +
> +return qemuMonitorJSONNBDServerAdd(mon, deviceID, writable);
> +}
> diff --git a/src/qemu/qemu_monitor.h b/src/qemu/qemu_monitor.h
> index eb069ed..33c772f 100644
> --- a/src/qemu/qemu_monitor.h
> +++ b/src/qemu/qemu_monitor.h
> @@ -634,6 +634,9 @@ char *qemuMonitorGetTargetArch(qemuMonitorPtr mon);
> int qemuMonitorNBDServerStart(qemuMonitorPtr mon,
>const char *host,
>unsigned int port);
> +int qemuMonitorNBDServerAdd(qemuMonitorPtr mon,
> +const char *deviceID,
> +bool writable);
> /**
> * When running two dd process and using <> redirection, we need a
> * shell that will not truncate files. These two strings serve that
> diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c
> index 545285d..1f2951f 100644
> --- a/src/qemu/qemu_monitor_json.c
> +++ b/src/qemu/qemu_monitor_json.c
> @@ -4322,3 +4322,28 @@ cleanup:
> virJSONValueFree(data);
> return ret;
> }
> +
> +int
> +qemuMonitorJSONNBDServerAdd(qemuMonitorPtr mon,
> +const char *deviceID,
> +bool writable)
> +{
> +int ret = -1;
> +virJSONValuePtr cmd;
> +virJSONValuePtr reply = NULL;
> +
> +if (!(cmd = qemuMonitorJSONMakeCommand("nbd-server-add",
> + "s:device", deviceID,
> + "b:writable", writable,
> + NULL)))
> +return ret;
> +
> +ret = qemuMonitorJSONCommand(mon, cmd, &reply);
> +
> +if (ret == 0)
> +ret = qemuMonitorJSONCheckError(cmd, reply);
> +
> +virJSONValueFree(cmd);
> +virJSONValueFree(reply);
> +return ret;
> +}
> diff --git a/src/qemu/qemu_monitor_json.h b/src/qemu/qemu_monitor_json.h
> index 0e43e39..14bd59f 100644
> --- a/src/qemu/qemu_monitor_json.h
> +++ b/src/qemu/qemu_monitor_json.h
> @@ -327,4 +327,7 @@ char *qemuMonitorJSONGetTargetArch(qemuMonitorPtr mon);
> int qemuMonitorJSONNBDServerStart(qemuMonitorPtr mon,
>const char *host,
>unsigned int port);
> +int qemuMonitorJSONNBDServerAdd(qemuMonitorPtr mon,
> +const char *deviceID,
> +bool writable);
> #endif /* QEMU_MONITOR_JSON_H */
--
regards!
li guang
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2.1 02/11] Introduce NBD migration cookie
IN) < 0)
> @@ -1702,8 +1790,12 @@ done:
> else
> cookieFlags = QEMU_MIGRATION_COOKIE_GRAPHICS;
>
> -if (qemuMigrationBakeCookie(mig, driver, vm, cookieout, cookieoutlen,
> -cookieFlags) < 0) {
> +/* dummy place holder for real work */
> +nbdPort = 0;
> +cookieFlags |= QEMU_MIGRATION_COOKIE_NBD;
> +
> +if (qemuMigrationBakeCookie(mig, driver, vm, nbdPort,
> +cookieout, cookieoutlen, cookieFlags) < 0) {
> /* We could tear down the whole guest here, but
> * cookie data is (so far) non-critical, so that
> * seems a little harsh. We'll just warn for now.
> @@ -2198,6 +2290,7 @@ qemuMigrationRun(virQEMUDriverPtr driver,
> int fd = -1;
> unsigned long migrate_speed = resource ? resource :
> priv->migMaxBandwidth;
> virErrorPtr orig_err = NULL;
> +unsigned int cookieFlags = QEMU_MIGRATION_COOKIE_GRAPHICS;
>
> VIR_DEBUG("driver=%p, vm=%p, cookiein=%s, cookieinlen=%d, "
>"cookieout=%p, cookieoutlen=%p, flags=%lx, resource=%lu, "
> @@ -2206,6 +2299,16 @@ qemuMigrationRun(virQEMUDriverPtr driver,
>cookieout, cookieoutlen, flags, resource,
>spec, spec->destType, spec->fwdType);
>
> +if (flags & VIR_MIGRATE_NON_SHARED_DISK) {
> +migrate_flags |= QEMU_MONITOR_MIGRATE_NON_SHARED_DISK;
> +cookieFlags |= QEMU_MIGRATION_COOKIE_NBD;
> +}
> +
> +if (flags & VIR_MIGRATE_NON_SHARED_INC) {
> +migrate_flags |= QEMU_MONITOR_MIGRATE_NON_SHARED_INC;
> +cookieFlags |= QEMU_MIGRATION_COOKIE_NBD;
> +}
> +
> if (virLockManagerPluginUsesState(driver->lockManager) &&
> !cookieout) {
> virReportError(VIR_ERR_INTERNAL_ERROR,
> @@ -2215,9 +2318,12 @@ qemuMigrationRun(virQEMUDriverPtr driver,
> return -1;
> }
>
> -if (!(mig = qemuMigrationEatCookie(driver, vm, cookiein, cookieinlen,
> - QEMU_MIGRATION_COOKIE_GRAPHICS)))
> +if (!(mig = qemuMigrationEatCookie(driver, vm, cookiein,
> + cookieinlen, cookieFlags))) {
> +cookieFlags &= ~QEMU_MIGRATION_COOKIE_GRAPHICS;
> goto cleanup;
> +}
> +cookieFlags &= ~QEMU_MIGRATION_COOKIE_GRAPHICS;
>
> if (qemuDomainMigrateGraphicsRelocate(driver, vm, mig) < 0)
> VIR_WARN("unable to provide data for graphics client relocation");
> @@ -2249,11 +2355,6 @@ qemuMigrationRun(virQEMUDriverPtr driver,
> goto cleanup;
> }
>
> -if (flags & VIR_MIGRATE_NON_SHARED_DISK)
> -migrate_flags |= QEMU_MONITOR_MIGRATE_NON_SHARED_DISK;
> -
> -if (flags & VIR_MIGRATE_NON_SHARED_INC)
> -migrate_flags |= QEMU_MONITOR_MIGRATE_NON_SHARED_INC;
>
> /* connect to the destination qemu if needed */
> if (spec->destType == MIGRATION_DEST_CONNECT_HOST &&
> @@ -2361,10 +2462,11 @@ cleanup:
> VIR_FORCE_CLOSE(fd);
> }
>
> +cookieFlags |= (QEMU_MIGRATION_COOKIE_PERSISTENT |
> +QEMU_MIGRATION_COOKIE_NETWORK);
> if (ret == 0 &&
> -qemuMigrationBakeCookie(mig, driver, vm, cookieout, cookieoutlen,
> -QEMU_MIGRATION_COOKIE_PERSISTENT |
> -QEMU_MIGRATION_COOKIE_NETWORK) < 0) {
> +qemuMigrationBakeCookie(mig, driver, vm, -1, cookieout,
> +cookieoutlen, cookieFlags) < 0) {
> VIR_WARN("Unable to encode migration cookie");
> }
>
> @@ -3301,7 +3403,7 @@ qemuMigrationFinish(virQEMUDriverPtr driver,
> int newVM = 1;
> qemuMigrationCookiePtr mig = NULL;
> virErrorPtr orig_err = NULL;
> -int cookie_flags = 0;
> +int cookieFlags = 0;
> qemuDomainObjPrivatePtr priv = vm->privateData;
>
> VIR_DEBUG("driver=%p, dconn=%p, vm=%p, cookiein=%s, cookieinlen=%d, "
> @@ -3318,12 +3420,12 @@ qemuMigrationFinish(virQEMUDriverPtr driver,
>
> qemuDomainCleanupRemove(vm, qemuMigrationPrepareCleanup);
>
> -cookie_flags = QEMU_MIGRATION_COOKIE_NETWORK;
> +cookieFlags = QEMU_MIGRATION_COOKIE_NETWORK | QEMU_MIGRATION_COOKIE_NBD;
> if (flags & VIR_MIGRATE_PERSIST_DEST)
> -cookie_flags |= QEMU_MIGRATION_COOKIE_PERSISTENT;
> +cookieFlags |= QEMU_MIGRATION_COOKIE_PERSISTENT;
>
> if (!(mig = qemuMigrationEatCookie(driver, vm, cookiein,
> - cookieinlen, cookie_flags)))
> + cookieinlen, cookieFlags)))
> goto endjob;
>
> /* Did the migration go as planned? If yes, return the domain
> @@ -3470,7 +3572,8 @@ qemuMigrationFinish(virQEMUDriverPtr driver,
> VIR_DOMAIN_EVENT_STOPPED_FAILED);
> }
>
> -if (qemuMigrationBakeCookie(mig, driver, vm, cookieout, cookieoutlen, 0)
> < 0)
> +if (qemuMigrationBakeCookie(mig, driver, vm, 0,
> +cookieout, cookieoutlen, 0) < 0)
> VIR_WARN("Unable to encode migration cookie");
>
> endjob:
--
regards!
li guang
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2.1 01/11] qemu: Introduce NBD_SERVER capability
reviewed-by: liguang
在 2012-12-18二的 15:36 +0100，Michal Privoznik写道：
> This just keeps track whether qemu knows nbd-server-* commands
> so we can use it during migration or not.
> ---
> src/qemu/qemu_capabilities.c | 3 +++
> src/qemu/qemu_capabilities.h | 1 +
> 2 files changed, 4 insertions(+)
>
> diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
> index 104a3f8..81e6d97 100644
> --- a/src/qemu/qemu_capabilities.c
> +++ b/src/qemu/qemu_capabilities.c
> @@ -200,6 +200,7 @@ VIR_ENUM_IMPL(qemuCaps, QEMU_CAPS_LAST,
>"cirrus-vga",
>"vmware-svga",
>"device-video-primary",
> + "nbd-server-start",
> );
>
> struct _qemuCaps {
> @@ -1963,6 +1964,8 @@ qemuCapsProbeQMPCommands(qemuCapsPtr caps,
> qemuCapsSet(caps, QEMU_CAPS_DRIVE_MIRROR);
> else if (STREQ(name, "blockdev-snapshot-sync"))
> qemuCapsSet(caps, QEMU_CAPS_DISK_SNAPSHOT);
> +else if (STREQ(name, "nbd-server-start"))
> +qemuCapsSet(caps, QEMU_CAPS_NBD_SERVER);
> VIR_FREE(name);
> }
> VIR_FREE(commands);
> diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
> index bf4eef8..2e7d0c4 100644
> --- a/src/qemu/qemu_capabilities.h
> +++ b/src/qemu/qemu_capabilities.h
> @@ -162,6 +162,7 @@ enum qemuCapsFlags {
> QEMU_CAPS_DEVICE_VMWARE_SVGA = 122, /* -device vmware-svga */
> QEMU_CAPS_DEVICE_VIDEO_PRIMARY = 123, /* safe to use -device XXX
> for primary video device */
> +QEMU_CAPS_NBD_SERVER = 124, /* nbd-server-start QMP command */
>
> QEMU_CAPS_LAST, /* this must always be the last item */
> };
--
regards!
li guang
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 02/11] Introduce NBD migration cookie
r, vm, QEMU_ASYNC_JOB_MIGRATION_IN) < 0)
> @@ -1640,8 +1728,12 @@ qemuMigrationPrepareAny(virQEMUDriverPtr driver,
> VIR_DEBUG("Received no lockstate");
> }
>
> -if (qemuMigrationBakeCookie(mig, driver, vm, cookieout, cookieoutlen,
> -QEMU_MIGRATION_COOKIE_GRAPHICS) < 0) {
> +/* dummy place holder for real work */
> +nbdPort = 0;
> +cookie_flags |= QEMU_MIGRATION_COOKIE_NBD;
> +
> +if (qemuMigrationBakeCookie(mig, driver, vm, nbdPort,
> +cookieout, cookieoutlen, cookie_flags) < 0) {
> /* We could tear down the whole guest here, but
> * cookie data is (so far) non-critical, so that
> * seems a little harsh. We'll just warn for now.
> @@ -2150,7 +2242,8 @@ qemuMigrationRun(virQEMUDriverPtr driver,
> }
>
> if (!(mig = qemuMigrationEatCookie(driver, vm, cookiein, cookieinlen,
> - QEMU_MIGRATION_COOKIE_GRAPHICS)))
> + QEMU_MIGRATION_COOKIE_GRAPHICS |
> + QEMU_MIGRATION_COOKIE_NBD)))
> goto cleanup;
>
> if (qemuDomainMigrateGraphicsRelocate(driver, vm, mig) < 0)
> @@ -2296,9 +2389,10 @@ cleanup:
> }
>
> if (ret == 0 &&
> -qemuMigrationBakeCookie(mig, driver, vm, cookieout, cookieoutlen,
> +qemuMigrationBakeCookie(mig, driver, vm, -1, cookieout, cookieoutlen,
> QEMU_MIGRATION_COOKIE_PERSISTENT |
> -QEMU_MIGRATION_COOKIE_NETWORK) < 0) {
> +QEMU_MIGRATION_COOKIE_NETWORK |
> +QEMU_MIGRATION_COOKIE_NBD) < 0) {
> VIR_WARN("Unable to encode migration cookie");
> }
>
> @@ -3233,7 +3327,7 @@ qemuMigrationFinish(virQEMUDriverPtr driver,
>
> qemuDomainCleanupRemove(vm, qemuMigrationPrepareCleanup);
>
> -cookie_flags = QEMU_MIGRATION_COOKIE_NETWORK;
> +cookie_flags = QEMU_MIGRATION_COOKIE_NETWORK | QEMU_MIGRATION_COOKIE_NBD;
> if (flags & VIR_MIGRATE_PERSIST_DEST)
> cookie_flags |= QEMU_MIGRATION_COOKIE_PERSISTENT;
>
> @@ -3377,7 +3471,8 @@ qemuMigrationFinish(virQEMUDriverPtr driver,
> VIR_DOMAIN_EVENT_STOPPED_FAILED);
> }
>
> -if (qemuMigrationBakeCookie(mig, driver, vm, cookieout, cookieoutlen, 0)
> < 0)
> +if (qemuMigrationBakeCookie(mig, driver, vm, 0,
> +cookieout, cookieoutlen, 0) < 0)
> VIR_WARN("Unable to encode migration cookie");
>
> endjob:
--
regards!
li guang
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 06/11] qemu_migration: Introduce qemuMigrationStartNBDServer
*/
> +if (qemuMigrationStartNBDServer(driver, vm, &nbdPort) < 0) {
> +/* error already reported */
> +goto endjob;
> +}
> +cookie_flags |= QEMU_MIGRATION_COOKIE_NBD;
> +}
>
> if (qemuMigrationBakeCookie(mig, driver, vm, nbdPort,
> cookieout, cookieoutlen, cookie_flags) < 0) {
> @@ -1800,21 +1832,23 @@ qemuMigrationPrepareTunnel(virQEMUDriverPtr driver,
> int *cookieoutlen,
> virStreamPtr st,
> const char *dname,
> - const char *dom_xml)
> + const char *dom_xml,
> + unsigned long flags)
> {
> int ret;
>
> VIR_DEBUG("driver=%p, dconn=%p, cookiein=%s, cookieinlen=%d, "
> - "cookieout=%p, cookieoutlen=%p, st=%p, dname=%s, dom_xml=%s",
> + "cookieout=%p, cookieoutlen=%p, st=%p, dname=%s, dom_xml=%s "
> + "flags=%lx",
>driver, dconn, NULLSTR(cookiein), cookieinlen,
> - cookieout, cookieoutlen, st, NULLSTR(dname), dom_xml);
> + cookieout, cookieoutlen, st, NULLSTR(dname), dom_xml, flags);
>
> /* QEMU will be started with -incoming stdio (which qemu_command might
> * convert to exec:cat or fd:n)
> */
> ret = qemuMigrationPrepareAny(driver, dconn, cookiein, cookieinlen,
>cookieout, cookieoutlen, dname, dom_xml,
> - "stdio", st);
> + "stdio", st, flags);
> return ret;
> }
>
> @@ -1829,7 +1863,8 @@ qemuMigrationPrepareDirect(virQEMUDriverPtr driver,
> const char *uri_in,
> char **uri_out,
> const char *dname,
> - const char *dom_xml)
> + const char *dom_xml,
> + unsigned long flags)
> {
> static int port = 0;
> int this_port;
> @@ -1840,10 +1875,10 @@ qemuMigrationPrepareDirect(virQEMUDriverPtr driver,
>
> VIR_DEBUG("driver=%p, dconn=%p, cookiein=%s, cookieinlen=%d, "
>"cookieout=%p, cookieoutlen=%p, uri_in=%s, uri_out=%p, "
> - "dname=%s, dom_xml=%s",
> + "dname=%s, dom_xml=%s flags=%lx",
>driver, dconn, NULLSTR(cookiein), cookieinlen,
>cookieout, cookieoutlen, NULLSTR(uri_in), uri_out,
> - NULLSTR(dname), dom_xml);
> + NULLSTR(dname), dom_xml, flags);
>
> /* The URI passed in may be NULL or a string "tcp://somehostname:port".
> *
> @@ -1925,7 +1960,7 @@ qemuMigrationPrepareDirect(virQEMUDriverPtr driver,
>
> ret = qemuMigrationPrepareAny(driver, dconn, cookiein, cookieinlen,
>cookieout, cookieoutlen, dname, dom_xml,
> - migrateFrom, NULL);
> + migrateFrom, NULL, flags);
> cleanup:
> VIR_FREE(hostname);
> if (ret != 0)
> diff --git a/src/qemu/qemu_migration.h b/src/qemu/qemu_migration.h
> index 62e39a0..c961866 100644
> --- a/src/qemu/qemu_migration.h
> +++ b/src/qemu/qemu_migration.h
> @@ -97,7 +97,8 @@ int qemuMigrationPrepareTunnel(virQEMUDriverPtr driver,
> int *cookieoutlen,
> virStreamPtr st,
> const char *dname,
> - const char *dom_xml);
> + const char *dom_xml,
> + unsigned long flags);
>
> int qemuMigrationPrepareDirect(virQEMUDriverPtr driver,
> virConnectPtr dconn,
> @@ -108,7 +109,8 @@ int qemuMigrationPrepareDirect(virQEMUDriverPtr driver,
> const char *uri_in,
> char **uri_out,
> const char *dname,
> - const char *dom_xml);
> + const char *dom_xml,
> + unsigned long flags);
>
> int qemuMigrationPerform(virQEMUDriverPtr driver,
> virConnectPtr conn,
--
regards!
li guang
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v16] support offline migration
ate(vm, NULL) == VIR_DOMAIN_PAUSED) {
> -virDomainObjSetState(vm, VIR_DOMAIN_PAUSED,
> VIR_DOMAIN_PAUSED_USER);
> -if (event)
> -qemuDomainEventQueue(driver, event);
> +if (!(flags & VIR_MIGRATE_OFFLINE)) {
> event = virDomainEventNewFromObj(vm,
> - VIR_DOMAIN_EVENT_SUSPENDED,
> -
> VIR_DOMAIN_EVENT_SUSPENDED_PAUSED);
> + VIR_DOMAIN_EVENT_RESUMED,
> +
> VIR_DOMAIN_EVENT_RESUMED_MIGRATED);
> +if (virDomainObjGetState(vm, NULL) == VIR_DOMAIN_PAUSED) {
> +virDomainObjSetState(vm, VIR_DOMAIN_PAUSED,
> + VIR_DOMAIN_PAUSED_USER);
> +if (event)
> +qemuDomainEventQueue(driver, event);
> +event = virDomainEventNewFromObj(vm,
> + VIR_DOMAIN_EVENT_SUSPENDED,
> +
> VIR_DOMAIN_EVENT_SUSPENDED_PAUSED);
> +}
> }
> -if (virDomainSaveStatus(driver->caps, driver->stateDir, vm) < 0) {
> +
> +if (virDomainObjIsActive(vm) &&
> +virDomainSaveStatus(driver->caps, driver->stateDir, vm) < 0) {
> VIR_WARN("Failed to save status on vm %s", vm->def->name);
> goto endjob;
> }
>
> /* Guest is successfully running, so cancel previous auto destroy */
> qemuProcessAutoDestroyRemove(driver, vm);
> -} else {
> +} else if (!(flags & VIR_MIGRATE_OFFLINE)) {
> qemuProcessStop(driver, vm, VIR_DOMAIN_SHUTOFF_FAILED,
> VIR_QEMU_PROCESS_STOP_MIGRATED);
> virDomainAuditStop(vm, "failed");
> @@ -3430,6 +3516,9 @@ int qemuMigrationConfirm(virQEMUDriverPtr driver,
> if (!(mig = qemuMigrationEatCookie(driver, vm, cookiein, cookieinlen,
> 0)))
> return -1;
>
> +if (flags & VIR_MIGRATE_OFFLINE)
> +goto done;
> +
> /* Did the migration go as planned? If yes, kill off the
> * domain object, but if no, resume CPUs
> */
> @@ -3465,6 +3554,7 @@ int qemuMigrationConfirm(virQEMUDriverPtr driver,
> }
> }
>
> +done:
> qemuMigrationCookieFree(mig);
> rv = 0;
>
> diff --git a/src/qemu/qemu_migration.h b/src/qemu/qemu_migration.h
> index 62e39a0..eb30f06 100644
> --- a/src/qemu/qemu_migration.h
> +++ b/src/qemu/qemu_migration.h
> @@ -36,7 +36,8 @@
> VIR_MIGRATE_NON_SHARED_DISK | \
> VIR_MIGRATE_NON_SHARED_INC | \
> VIR_MIGRATE_CHANGE_PROTECTION |\
> - VIR_MIGRATE_UNSAFE)
> + VIR_MIGRATE_UNSAFE | \
> + VIR_MIGRATE_OFFLINE)
>
> enum qemuMigrationJobPhase {
> QEMU_MIGRATION_PHASE_NONE = 0,
> @@ -97,7 +98,8 @@ int qemuMigrationPrepareTunnel(virQEMUDriverPtr driver,
> int *cookieoutlen,
> virStreamPtr st,
> const char *dname,
> - const char *dom_xml);
> + const char *dom_xml,
> + unsigned long flags);
>
> int qemuMigrationPrepareDirect(virQEMUDriverPtr driver,
> virConnectPtr dconn,
> @@ -108,7 +110,8 @@ int qemuMigrationPrepareDirect(virQEMUDriverPtr driver,
> const char *uri_in,
> char **uri_out,
> const char *dname,
> - const char *dom_xml);
> + const char *dom_xml,
> + unsigned long flags);
>
> int qemuMigrationPerform(virQEMUDriverPtr driver,
> virConnectPtr conn,
> diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
> index 96e62fc..39ac9b5 100644
> --- a/tools/virsh-domain.c
> +++ b/tools/virsh-domain.c
> @@ -6803,6 +6803,7 @@ static const vshCmdInfo info_migrate[] = {
>
> static const vshCmdOptDef opts_migrate[] = {
> {"live", VSH_OT_BOOL, 0, N_("live migration")},
> +{"offline", VSH_OT_BOOL, 0, N_("offline (domain's inactive) migration")},
> {"p2p", VSH_OT_BOOL, 0, N_("peer-2-peer migration")},
> {"direct", VSH_OT_BOOL, 0, N_("direct migration")},
> {"tunneled", VSH_OT_ALIAS, 0, "tunnelled"},
> @@ -6888,6 +6889,10 @@ doMigrate(void *opaque)
> if (vshCommandOptBool(cmd, "unsafe"))
> flags |= VIR_MIGRATE_UNSAFE;
>
> +if (vshCommandOptBool(cmd, "offline")) {
> +flags |= VIR_MIGRATE_OFFLINE;
> +}
> +
> if (xmlfile &&
> virFileReadAll(xmlfile, 8192, &xml) < 0) {
> vshError(ctl, _("file '%s' doesn't exist"), xmlfile);
> diff --git a/tools/virsh.pod b/tools/virsh.pod
> index b0e7064..0ada19a 100644
> --- a/tools/virsh.pod
> +++ b/tools/virsh.pod
> @@ -1040,13 +1040,14 @@ I<--total> for only the total stats, I for
> only the per-cpu
> stats of the CPUs from I, I for only I CPUs'
> stats.
>
> -=item B [I<--live>] [I<--direct>] [I<--p2p> [I<--tunnelled>]]
> +=item B [I<--live>] [I<--offline>] [I<--direct>] [I<--p2p>
> [I<--tunnelled>]]
> [I<--persistent>] [I<--undefinesource>] [I<--suspend>]
> [I<--copy-storage-all>]
> [I<--copy-storage-inc>] [I<--change-protection>] [I<--unsafe>] [I<--verbose>]
> I I [I] [I]
> [I<--timeout> B] [I<--xml> B]
>
> -Migrate domain to another host. Add I<--live> for live migration; I<--p2p>
> +Migrate domain to another host. Add I<--live> for live migration;
> +I<--offline> for offline (domain's inactive) migration; <--p2p>
> for peer-2-peer migration; I<--direct> for direct migration; or
> I<--tunnelled>
> for tunnelled migration. I<--persistent> leaves the domain persistent on
> destination host, I<--undefinesource> undefines the domain on the source
> host,
--
regards!
li guang
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v15] support offline migration
prevents any other APIs being invoked while incoming
> @@ -2702,12 +2734,18 @@ static int doPeer2PeerMigrate3(virQEMUDriverPtr
> driver,
> uri, &uri_out, flags, dname, resource, dom_xml);
> qemuDomainObjExitRemoteWithDriver(driver, vm);
> }
> -
> VIR_FREE(dom_xml);
> -
> if (ret == -1)
> goto cleanup;
>
> +if (flags & VIR_MIGRATE_OFFLINE) {
> +VIR_DEBUG("Offline migration, skipping Perform phase");
> +VIR_FREE(cookieout);
> +cookieoutlen = 0;
> +cancelled = 0;
> +goto finish;
> +}
> +
> if (!(flags & VIR_MIGRATE_TUNNELLED) &&
> (uri_out == NULL)) {
> virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> @@ -2846,6 +2884,7 @@ static int doPeer2PeerMigrate(virQEMUDriverPtr driver,
> virConnectPtr dconn = NULL;
> bool p2p;
> virErrorPtr orig_err = NULL;
> +bool offline;
>
> VIR_DEBUG("driver=%p, sconn=%p, vm=%p, xmlin=%s, dconnuri=%s, "
>"uri=%s, flags=%lx, dname=%s, resource=%lu",
> @@ -2878,6 +2917,9 @@ static int doPeer2PeerMigrate(virQEMUDriverPtr driver,
> */
> *v3proto = VIR_DRV_SUPPORTS_FEATURE(dconn->driver, dconn,
> VIR_DRV_FEATURE_MIGRATION_V3);
> +if (flags & VIR_MIGRATE_OFFLINE)
> +offline = VIR_DRV_SUPPORTS_FEATURE(dconn->driver, dconn,
> +
> VIR_DRV_FEATURE_MIGRATION_OFFLINE);
> qemuDomainObjExitRemoteWithDriver(driver, vm);
>
> if (!p2p) {
> @@ -2886,6 +2928,13 @@ static int doPeer2PeerMigrate(virQEMUDriverPtr driver,
> goto cleanup;
> }
>
> +if (flags & VIR_MIGRATE_OFFLINE && !offline) {
> +virReportError(VIR_ERR_ARGUMENT_UNSUPPORTED, "%s",
> + _("offline migration is not supported by "
> + "the destination host"));
> +goto cleanup;
> +}
> +
> /* domain may have been stopped while we were talking to remote daemon */
> if (!virDomainObjIsActive(vm) && !(flags & VIR_MIGRATE_OFFLINE)) {
> virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> @@ -3320,9 +3369,11 @@ qemuMigrationFinish(virQEMUDriverPtr driver,
> * to restart during confirm() step, so we kill it off now.
> */
> if (v3proto) {
> -qemuProcessStop(driver, vm, VIR_DOMAIN_SHUTOFF_FAILED,
> -VIR_QEMU_PROCESS_STOP_MIGRATED);
> -virDomainAuditStop(vm, "failed");
> +if (!(flags & VIR_MIGRATE_OFFLINE)) {
> +qemuProcessStop(driver, vm,
> VIR_DOMAIN_SHUTOFF_FAILED,
> +VIR_QEMU_PROCESS_STOP_MIGRATED);
> +virDomainAuditStop(vm, "failed");
> +}
> if (newVM)
> vm->persistent = 0;
> }
> @@ -3395,16 +3446,15 @@ qemuMigrationFinish(virQEMUDriverPtr driver,
> }
> }
>
> -if (virDomainObjIsActive(vm)) {
> -if (virDomainSaveStatus(driver->caps, driver->stateDir, vm) < 0)
> {
> -VIR_WARN("Failed to save status on vm %s", vm->def->name);
> -goto endjob;
> -}
> +if (virDomainObjIsActive(vm) &&
> +virDomainSaveStatus(driver->caps, driver->stateDir, vm) < 0) {
> +VIR_WARN("Failed to save status on vm %s", vm->def->name);
> +goto endjob;
> }
>
> /* Guest is successfully running, so cancel previous auto destroy */
> qemuProcessAutoDestroyRemove(driver, vm);
> -} else {
> +} else if (!(flags & VIR_MIGRATE_OFFLINE)) {
> qemuProcessStop(driver, vm, VIR_DOMAIN_SHUTOFF_FAILED,
> VIR_QEMU_PROCESS_STOP_MIGRATED);
> virDomainAuditStop(vm, "failed");
--
regards!
li guang
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 4/4] util: Do not keep PCI device config file open
在 2012-12-04二的 23:23 +0100，Jiri Denemark写道：
> Directly open and close PCI config file in the APIs that need it rather
> than keeping the file open for the whole life of PCI device structure.
> ---
> src/util/pci.c | 265
> +
> 1 file changed, 156 insertions(+), 109 deletions(-)
>
> diff --git a/src/util/pci.c b/src/util/pci.c
> index e410245..8bded78 100644
[snip]
> /* otherwise, SRIOV allows VFs to be on different busses then their PFs.
> * In this case, what we need to do is look for the "best" match; i.e.
> @@ -557,25 +572,38 @@ pciIsParent(pciDevice *dev, pciDevice *check, void
> *data)
> if (*best == NULL) {
> *best = pciGetDevice(check->domain, check->bus, check->slot,
> check->function);
> -if (*best == NULL)
> -return -1;
> -}
> -else {
--** --
> +if (*best == NULL) {
> +ret = -1;
> +goto cleanup;
> +}
--first--
> +} else {
> /* OK, we had already recorded a previous "best" match for the
> * parent. See if the current device is more restrictive than
> the
> * best, and if so, make it the new best
> */
> -if (secondary > pciRead8(*best, PCI_SECONDARY_BUS)) {
> +int bestfd;
> +uint8_t best_secondary;
> +
> +if ((bestfd = pciConfigOpen(*best, false)) < 0)
> +goto cleanup;
> +best_secondary = pciRead8(*best, bestfd, PCI_SECONDARY_BUS);
> +pciConfigClose(*best, bestfd);
> +
> +if (secondary > best_secondary) {
> pciFreeDevice(*best);
> *best = pciGetDevice(check->domain, check->bus, check->slot,
> check->function);
> -if (*best == NULL)
> -return -1;
--** --
> +if (*best == NULL) {
> +ret = -1;
> +goto cleanup;
> +}
--second--
> }
> }
logically, the 2 'if (*best == NULL) {'
can be combined and plcaced here.
> }
>
> -return 0;
> +cleanup:
> +pciConfigClose(check, fd);
> +return ret;
> }
>
> static int
> @@ -598,12 +626,14 @@ pciGetParentDevice(pciDevice *dev, pciDevice **parent)
> */
[snip]
> @@ -669,7 +704,7 @@ out:
> * above we require the device supports a full internal reset.
> */
> static int
> -pciTryPowerManagementReset(pciDevice *dev)
> +pciTryPowerManagementReset(pciDevice *dev, int cfgfd)
> {
> uint8_t config_space[PCI_CONF_LEN];
> uint32_t ctl;
> @@ -678,7 +713,7 @@ pciTryPowerManagementReset(pciDevice *dev)
> return -1;
>
> /* Save and restore the device's config space. */
> -if (pciRead(dev, 0, &config_space[0], PCI_CONF_LEN) < 0) {
> +if (pciRead(dev, cfgfd, 0, &config_space[0], PCI_CONF_LEN) < 0) {
> virReportError(VIR_ERR_INTERNAL_ERROR,
> _("Failed to read PCI config space for %s"),
> dev->name);
> @@ -687,18 +722,20 @@ pciTryPowerManagementReset(pciDevice *dev)
>
> VIR_DEBUG("%s %s: doing a power management reset", dev->id, dev->name);
>
> -ctl = pciRead32(dev, dev->pci_pm_cap_pos + PCI_PM_CTRL);
> +ctl = pciRead32(dev, cfgfd, dev->pci_pm_cap_pos + PCI_PM_CTRL);
> ctl &= ~PCI_PM_CTRL_STATE_MASK;
>
> -pciWrite32(dev, dev->pci_pm_cap_pos + PCI_PM_CTRL,
> ctl|PCI_PM_CTRL_STATE_D3hot);
seems more than 80 characters
> +pciWrite32(dev, cfgfd, dev->pci_pm_cap_pos + PCI_PM_CTRL,
> + ctl | PCI_PM_CTRL_STATE_D3hot);
>
> usleep(10 * 1000); /* sleep 10ms */
>
> -pciWrite32(dev, dev->pci_pm_cap_pos + PCI_PM_CTRL,
> ctl|PCI_PM_CTRL_STATE_D0);
> +pciWrite32(dev, cfgfd, dev->pci_pm_cap_pos + PCI_PM_CTRL,
> + ctl | PCI_PM_CTRL_STATE_D0);
>
> usleep(10 * 1000); /* sleep 10ms */
>
> -if (pciWrite(dev, 0, &config_space[0], PCI_CONF_LEN) < 0) {
> +if (pciWrite(dev, cfgfd, 0, &config_space[0], PCI_CONF_LEN) < 0) {
> virReportError(VIR_ERR_INTERNAL_ERROR,
> _("Failed to restore PCI config space for %s"),
> dev->name);
[snip]
--
regards!
li guang
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v15] support offline migration
Hi, Jirka Please ... Thanks! 在 2012-11-27二的 09:22 +0100，Jiri Denemark写道： > On Tue, Nov 27, 2012 at 08:45:24 +0800, li guang wrote: > > Hi, Jirka > > > > waiting for your comment ... > > Hi, > > Don't worry, I returned from vacation yesterday and I'll get to your patch > sometime this week. > > Jirka -- regards! li guang -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v1 06/11] qemu_migration: Introduce qemuMigrationStartNBDServer
nNextPort() (08/11) not by
cookie element 'nbd/port' (02/11), as a result, seems the previous
cookie baking is rather needless.
> +/* error already reported */
> +goto endjob;
> +}
> +cookie_flags |= QEMU_MIGRATION_COOKIE_NBD;
> +}
>
> if (qemuMigrationBakeCookie(mig, driver, vm, nbdPort,
> cookieout, cookieoutlen, cookie_flags) < 0) {
> @@ -1791,21 +1823,23 @@ qemuMigrationPrepareTunnel(struct qemud_driver
> *driver,
> int *cookieoutlen,
> virStreamPtr st,
> const char *dname,
> - const char *dom_xml)
> + const char *dom_xml,
> + unsigned long flags)
> {
> int ret;
>
> VIR_DEBUG("driver=%p, dconn=%p, cookiein=%s, cookieinlen=%d, "
> - "cookieout=%p, cookieoutlen=%p, st=%p, dname=%s, dom_xml=%s",
> + "cookieout=%p, cookieoutlen=%p, st=%p, dname=%s, dom_xml=%s "
> + "flags=%lx",
>driver, dconn, NULLSTR(cookiein), cookieinlen,
> - cookieout, cookieoutlen, st, NULLSTR(dname), dom_xml);
> + cookieout, cookieoutlen, st, NULLSTR(dname), dom_xml, flags);
>
> /* QEMU will be started with -incoming stdio (which qemu_command might
> * convert to exec:cat or fd:n)
> */
> ret = qemuMigrationPrepareAny(driver, dconn, cookiein, cookieinlen,
>cookieout, cookieoutlen, dname, dom_xml,
> - "stdio", st);
> + "stdio", st, flags);
> return ret;
> }
>
> @@ -1820,7 +1854,8 @@ qemuMigrationPrepareDirect(struct qemud_driver *driver,
> const char *uri_in,
> char **uri_out,
> const char *dname,
> - const char *dom_xml)
> + const char *dom_xml,
> + unsigned long flags)
> {
> static int port = 0;
> int this_port;
> @@ -1831,10 +1866,10 @@ qemuMigrationPrepareDirect(struct qemud_driver
> *driver,
>
> VIR_DEBUG("driver=%p, dconn=%p, cookiein=%s, cookieinlen=%d, "
>"cookieout=%p, cookieoutlen=%p, uri_in=%s, uri_out=%p, "
> - "dname=%s, dom_xml=%s",
> + "dname=%s, dom_xml=%s flags=%lx",
>driver, dconn, NULLSTR(cookiein), cookieinlen,
>cookieout, cookieoutlen, NULLSTR(uri_in), uri_out,
> - NULLSTR(dname), dom_xml);
> + NULLSTR(dname), dom_xml, flags);
>
> /* The URI passed in may be NULL or a string "tcp://somehostname:port".
> *
> @@ -1916,7 +1951,7 @@ qemuMigrationPrepareDirect(struct qemud_driver *driver,
>
> ret = qemuMigrationPrepareAny(driver, dconn, cookiein, cookieinlen,
>cookieout, cookieoutlen, dname, dom_xml,
> - migrateFrom, NULL);
> + migrateFrom, NULL, flags);
> cleanup:
> VIR_FREE(hostname);
> if (ret != 0)
> diff --git a/src/qemu/qemu_migration.h b/src/qemu/qemu_migration.h
> index 7a2269a..8e411ef 100644
> --- a/src/qemu/qemu_migration.h
> +++ b/src/qemu/qemu_migration.h
> @@ -97,7 +97,8 @@ int qemuMigrationPrepareTunnel(struct qemud_driver *driver,
> int *cookieoutlen,
> virStreamPtr st,
> const char *dname,
> - const char *dom_xml);
> + const char *dom_xml,
> + unsigned long flags);
>
> int qemuMigrationPrepareDirect(struct qemud_driver *driver,
> virConnectPtr dconn,
> @@ -108,7 +109,8 @@ int qemuMigrationPrepareDirect(struct qemud_driver
> *driver,
> const char *uri_in,
> char **uri_out,
> const char *dname,
> - const char *dom_xml);
> + const char *dom_xml,
> + unsigned long flags);
>
> int qemuMigrationPerform(struct qemud_driver *driver,
> virConnectPtr conn,
--
regards!
li guang
linux kernel team at FNST, china
thinking with brain but heart
living with heart but brain
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v1 00/11] Rework storage migration
在 2012-11-27二的 16:42 -0500，Eric Blake写道： > > This patch set re-implements migration with storage for enough new > > qemu. > > How does this series interact with Li Guang's efforts to add offline > migration? In particular, > > > 1) src -> dest: (QEMU_MIGRATION_PHASE_BEGIN3 -> > > QEMU_MIGRATION_PHASE_PREPARE) > > > > >size='17179869184'/> > > > > Both sets of patches need to pass size information across in the > cookies; so is tying it to appropriate, or should we be > rethinking this XML to be shared between both patches? actually, I think 'src' is unnecessary, for 'def->disks[i]->src' shared between src & dst, size and 'src' paired one by one, we will not make a mistake to match them. -- regards! li guang linux kernel team at FNST, china thinking with brain but heart living with heart but brain -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v15] support offline migration
\
> VIR_MIGRATE_NON_SHARED_INC | \
> VIR_MIGRATE_CHANGE_PROTECTION |\
> - VIR_MIGRATE_UNSAFE)
> + VIR_MIGRATE_UNSAFE | \
> + VIR_MIGRATE_OFFLINE)
>
> enum qemuMigrationJobPhase {
> QEMU_MIGRATION_PHASE_NONE = 0,
> @@ -97,7 +98,8 @@ int qemuMigrationPrepareTunnel(struct qemud_driver *driver,
> int *cookieoutlen,
> virStreamPtr st,
> const char *dname,
> - const char *dom_xml);
> + const char *dom_xml,
> + unsigned long flags);
>
> int qemuMigrationPrepareDirect(struct qemud_driver *driver,
> virConnectPtr dconn,
> @@ -108,7 +110,8 @@ int qemuMigrationPrepareDirect(struct qemud_driver
> *driver,
> const char *uri_in,
> char **uri_out,
> const char *dname,
> - const char *dom_xml);
> + const char *dom_xml,
> + unsigned long flags);
>
> int qemuMigrationPerform(struct qemud_driver *driver,
> virConnectPtr conn,
> diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
> index cc47383..5d18bdf 100644
> --- a/tools/virsh-domain.c
> +++ b/tools/virsh-domain.c
> @@ -6661,6 +6661,7 @@ static const vshCmdInfo info_migrate[] = {
>
> static const vshCmdOptDef opts_migrate[] = {
> {"live", VSH_OT_BOOL, 0, N_("live migration")},
> +{"offline", VSH_OT_BOOL, 0, N_("offline (domain's inactive) migration")},
> {"p2p", VSH_OT_BOOL, 0, N_("peer-2-peer migration")},
> {"direct", VSH_OT_BOOL, 0, N_("direct migration")},
> {"tunneled", VSH_OT_ALIAS, 0, "tunnelled"},
> @@ -6746,6 +6747,10 @@ doMigrate(void *opaque)
> if (vshCommandOptBool(cmd, "unsafe"))
> flags |= VIR_MIGRATE_UNSAFE;
>
> +if (vshCommandOptBool(cmd, "offline")) {
> +flags |= VIR_MIGRATE_OFFLINE;
> +}
> +
> if (xmlfile &&
> virFileReadAll(xmlfile, 8192, &xml) < 0) {
> vshError(ctl, _("file '%s' doesn't exist"), xmlfile);
> diff --git a/tools/virsh.pod b/tools/virsh.pod
> index 29be39e..b3ef64e 100644
> --- a/tools/virsh.pod
> +++ b/tools/virsh.pod
> @@ -1026,13 +1026,14 @@ I<--total> for only the total stats, I for
> only the per-cpu
> stats of the CPUs from I, I for only I CPUs'
> stats.
>
> -=item B [I<--live>] [I<--direct>] [I<--p2p> [I<--tunnelled>]]
> +=item B [I<--live>] [I<--offline>] [I<--direct>] [I<--p2p>
> [I<--tunnelled>]]
> [I<--persistent>] [I<--undefinesource>] [I<--suspend>]
> [I<--copy-storage-all>]
> [I<--copy-storage-inc>] [I<--change-protection>] [I<--unsafe>] [I<--verbose>]
> I I [I] [I]
> [I<--timeout> B] [I<--xml> B]
>
> -Migrate domain to another host. Add I<--live> for live migration; I<--p2p>
> +Migrate domain to another host. Add I<--live> for live migration;
> +I<--offline> for offline (domain's inactive) migration; <--p2p>
> for peer-2-peer migration; I<--direct> for direct migration; or
> I<--tunnelled>
> for tunnelled migration. I<--persistent> leaves the domain persistent on
> destination host, I<--undefinesource> undefines the domain on the source
> host,
--
regards!
li guang
linux kernel team at FNST, china
thinking with brain but heart
living with heart but brain
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v1 2/2][RFC] help to create disk images of non-shared migration
if (!virFileExists(tmp_dir))
> +if (virFileMakePath(tmp_dir) < 0)
> +continue;
> +if (STREQ(disk_format[def->disks[i]->format], "none"))
> +continue;
> +if (def->disks[i]->format < VIR_STORAGE_FILE_RAW)
> +goto error;
> +if (def->disks[i]->format >= VIR_STORAGE_FILE_LAST)
> +goto error;
> +
> +if (gen) {
> +char *dsize = mig->storage->disk[i].dsize;
> +cmd = virCommandNewArgList(img_tool, "create", "-f",
> + disk_format[def->disks[i]->format],
> + def->disks[i]->src, NULL);
> +virCommandAddArgFormat(cmd, "%s", dsize);
> +if (def->disks[i]->encryption)
> +virCommandAddArgList(cmd, "-o", "encryption=on", NULL);
> +virCommandSetOutputBuffer(cmd, &outbuf);
> +if (virCommandRun(cmd, NULL) < 0) {
> +virReportSystemError(errno, "%s", outbuf);
> +goto cleanup;
> +}
> + } else {
> +if (unlink(def->disks[i]->src) < 0) {
> +virReportError(errno, "%s", _("fail to unlink disk image
> file"));
> +goto cleanup;
> +}
> +}
> +virCommandFree(cmd);
> +VIR_FREE(tmp_dir);
> +VIR_FREE(outbuf);
> +}
> +
> +ret = 0;
> +
> +cleanup:
> +if (ret < 0) {
> +virCommandFree(cmd);
> +VIR_FREE(tmp_dir);
> +VIR_FREE(outbuf);
> +}
> +error:
> +return ret;
> +}
> +
> +
> /* Prepare is the first step, and it runs on the destination host.
> */
>
> @@ -1602,6 +1860,15 @@ qemuMigrationPrepareAny(struct qemud_driver *driver,
> /* virDomainAssignDef already set the error */
> goto cleanup;
> }
> +
> +if (!(mig = qemuMigrationEatCookie(driver, vm, cookiein, cookieinlen,
> + QEMU_MIGRATION_COOKIE_COPYSTORAGE)))
> +goto cleanup;
> +
> +if (flags & (VIR_MIGRATE_NON_SHARED_DISK | VIR_MIGRATE_NON_SHARED_INC))
> +if (qemuMigrationHandleDiskFiles(driver, def, true, mig) < 0)
> +goto endjob;
> +
> def = NULL;
> priv = vm->privateData;
> priv->origname = origname;
> @@ -3247,6 +3514,7 @@ qemuMigrationFinish(struct qemud_driver *driver,
> virErrorPtr orig_err = NULL;
> int cookie_flags = 0;
> qemuDomainObjPrivatePtr priv = vm->privateData;
> +bool migration_status = false;
>
> VIR_DEBUG("driver=%p, dconn=%p, vm=%p, cookiein=%s, cookieinlen=%d, "
>"cookieout=%p, cookieoutlen=%p, flags=%lx, retcode=%d",
> @@ -3416,7 +3684,12 @@ qemuMigrationFinish(struct qemud_driver *driver,
> if (qemuMigrationBakeCookie(mig, driver, vm, cookieout, cookieoutlen, 0)
> < 0)
> VIR_WARN("Unable to encode migration cookie");
>
> +migration_status = true;
> +
> endjob:
> +if (!migration_status && flags &
> +(VIR_MIGRATE_NON_SHARED_DISK | VIR_MIGRATE_NON_SHARED_INC))
> +qemuMigrationHandleDiskFiles(driver, vm->def, false, NULL);
> if (qemuMigrationJobFinish(driver, vm) == 0) {
> vm = NULL;
> } else if (!vm->persistent && !virDomainObjIsActive(vm)) {
--
regards!
li guang
linux kernel team at FNST, china
thinking with brain but heart
living with heart but brain
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v15] support offline migration
E_NON_SHARED_INC | \
> VIR_MIGRATE_CHANGE_PROTECTION |\
> - VIR_MIGRATE_UNSAFE)
> + VIR_MIGRATE_UNSAFE | \
> + VIR_MIGRATE_OFFLINE)
>
> enum qemuMigrationJobPhase {
> QEMU_MIGRATION_PHASE_NONE = 0,
> @@ -97,7 +98,8 @@ int qemuMigrationPrepareTunnel(struct qemud_driver *driver,
> int *cookieoutlen,
> virStreamPtr st,
> const char *dname,
> - const char *dom_xml);
> + const char *dom_xml,
> + unsigned long flags);
>
> int qemuMigrationPrepareDirect(struct qemud_driver *driver,
> virConnectPtr dconn,
> @@ -108,7 +110,8 @@ int qemuMigrationPrepareDirect(struct qemud_driver
> *driver,
> const char *uri_in,
> char **uri_out,
> const char *dname,
> - const char *dom_xml);
> + const char *dom_xml,
> + unsigned long flags);
>
> int qemuMigrationPerform(struct qemud_driver *driver,
> virConnectPtr conn,
> diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
> index cc47383..5d18bdf 100644
> --- a/tools/virsh-domain.c
> +++ b/tools/virsh-domain.c
> @@ -6661,6 +6661,7 @@ static const vshCmdInfo info_migrate[] = {
>
> static const vshCmdOptDef opts_migrate[] = {
> {"live", VSH_OT_BOOL, 0, N_("live migration")},
> +{"offline", VSH_OT_BOOL, 0, N_("offline (domain's inactive) migration")},
> {"p2p", VSH_OT_BOOL, 0, N_("peer-2-peer migration")},
> {"direct", VSH_OT_BOOL, 0, N_("direct migration")},
> {"tunneled", VSH_OT_ALIAS, 0, "tunnelled"},
> @@ -6746,6 +6747,10 @@ doMigrate(void *opaque)
> if (vshCommandOptBool(cmd, "unsafe"))
> flags |= VIR_MIGRATE_UNSAFE;
>
> +if (vshCommandOptBool(cmd, "offline")) {
> +flags |= VIR_MIGRATE_OFFLINE;
> +}
> +
> if (xmlfile &&
> virFileReadAll(xmlfile, 8192, &xml) < 0) {
> vshError(ctl, _("file '%s' doesn't exist"), xmlfile);
> diff --git a/tools/virsh.pod b/tools/virsh.pod
> index 29be39e..b3ef64e 100644
> --- a/tools/virsh.pod
> +++ b/tools/virsh.pod
> @@ -1026,13 +1026,14 @@ I<--total> for only the total stats, I for
> only the per-cpu
> stats of the CPUs from I, I for only I CPUs'
> stats.
>
> -=item B [I<--live>] [I<--direct>] [I<--p2p> [I<--tunnelled>]]
> +=item B [I<--live>] [I<--offline>] [I<--direct>] [I<--p2p>
> [I<--tunnelled>]]
> [I<--persistent>] [I<--undefinesource>] [I<--suspend>]
> [I<--copy-storage-all>]
> [I<--copy-storage-inc>] [I<--change-protection>] [I<--unsafe>] [I<--verbose>]
> I I [I] [I]
> [I<--timeout> B] [I<--xml> B]
>
> -Migrate domain to another host. Add I<--live> for live migration; I<--p2p>
> +Migrate domain to another host. Add I<--live> for live migration;
> +I<--offline> for offline (domain's inactive) migration; <--p2p>
> for peer-2-peer migration; I<--direct> for direct migration; or
> I<--tunnelled>
> for tunnelled migration. I<--persistent> leaves the domain persistent on
> destination host, I<--undefinesource> undefines the domain on the source
> host,
--
regards!
li guang
linux kernel team at FNST, china
thinking with brain but heart
living with heart but brain
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v1 2/2][RFC] help to create disk images of non-shared migration
ists(def->disks[i]->src))
> +continue;
> +if ((tmp_dir = mdir_name(def->disks[i]->src)) == NULL)
> +continue;
> +if (!virFileExists(tmp_dir))
> +if (virFileMakePath(tmp_dir) < 0)
> +continue;
> +if (STREQ(disk_format[def->disks[i]->format], "none"))
> +continue;
> +if (def->disks[i]->format < VIR_STORAGE_FILE_RAW)
> +goto error;
> +if (def->disks[i]->format >= VIR_STORAGE_FILE_LAST)
> +goto error;
> +
> +if (gen) {
> +char *dsize = mig->storage->disk[i].dsize;
> +cmd = virCommandNewArgList(img_tool, "create", "-f",
> + disk_format[def->disks[i]->format],
> + def->disks[i]->src, NULL);
> +virCommandAddArgFormat(cmd, "%s", dsize);
> +if (def->disks[i]->encryption)
> +virCommandAddArgList(cmd, "-o", "encryption=on", NULL);
> +virCommandSetOutputBuffer(cmd, &outbuf);
> +if (virCommandRun(cmd, NULL) < 0) {
> +virReportSystemError(errno, "%s", outbuf);
> +goto cleanup;
> +}
> +} else {
> +if (unlink(def->disks[i]->src) < 0) {
> +virReportError(errno, "%s", _("fail to unlink disk image
> file"));
> +goto cleanup;
> +}
> +}
> +virCommandFree(cmd);
> +VIR_FREE(tmp_dir);
> +VIR_FREE(outbuf);
> +}
> +
> +ret = 0;
> +
> +cleanup:
> +if (ret < 0) {
> +virCommandFree(cmd);
> +VIR_FREE(tmp_dir);
> +VIR_FREE(outbuf);
> +}
> +error:
> +return ret;
> +}
> +
> +
> /* Prepare is the first step, and it runs on the destination host.
> */
>
> @@ -1602,6 +1860,15 @@ qemuMigrationPrepareAny(struct qemud_driver *driver,
> /* virDomainAssignDef already set the error */
> goto cleanup;
> }
> +
> +if (!(mig = qemuMigrationEatCookie(driver, vm, cookiein, cookieinlen,
> + QEMU_MIGRATION_COOKIE_COPYSTORAGE)))
> +goto cleanup;
> +
> +if (flags & (VIR_MIGRATE_NON_SHARED_DISK | VIR_MIGRATE_NON_SHARED_INC))
> +if (qemuMigrationHandleDiskFiles(driver, def, true, mig) < 0)
> +goto endjob;
> +
> def = NULL;
> priv = vm->privateData;
> priv->origname = origname;
> @@ -3247,6 +3514,7 @@ qemuMigrationFinish(struct qemud_driver *driver,
> virErrorPtr orig_err = NULL;
> int cookie_flags = 0;
> qemuDomainObjPrivatePtr priv = vm->privateData;
> +bool migration_status = false;
>
> VIR_DEBUG("driver=%p, dconn=%p, vm=%p, cookiein=%s, cookieinlen=%d, "
>"cookieout=%p, cookieoutlen=%p, flags=%lx, retcode=%d",
> @@ -3416,7 +3684,12 @@ qemuMigrationFinish(struct qemud_driver *driver,
> if (qemuMigrationBakeCookie(mig, driver, vm, cookieout, cookieoutlen, 0)
> < 0)
> VIR_WARN("Unable to encode migration cookie");
>
> +migration_status = true;
> +
> endjob:
> +if (!migration_status && flags &
> +(VIR_MIGRATE_NON_SHARED_DISK | VIR_MIGRATE_NON_SHARED_INC))
> +qemuMigrationHandleDiskFiles(driver, vm->def, false, NULL);
> if (qemuMigrationJobFinish(driver, vm) == 0) {
> vm = NULL;
> } else if (!vm->persistent && !virDomainObjIsActive(vm)) {
--
li guang lig.f...@cn.fujitsu.com
linux kernel team at FNST, china
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v1 2/2] help to create disk images of non-shared migration
在 2012-11-22四的 13:41 +0800，li guang写道：
> 在 2012-11-21三的 23:21 -0600，Doug Goldstein写道：
> > On Nov 21, 2012, at 8:14 PM, li guang wrote:
> >
> > > ping ...
> >
> > The last review I asked that you drop the usage of qemu-img and use
> > libvirt's block APIs and extend them as necessary to make it easier to call
> > it. Otherwise you are duplicating functionality, not respecting the probe
> > option, and only supporting file types supported by qemu-img.
>
> yes, I'm considering your opinion,
> but, seems it's not so convenience to use that function, you know?
> or do you have a suitable way to call it during MigrationPrepareAny?
I mean during BakeCookie, it's hard to grab a virDomainPtr parameter
for qemuDomainGetBlockInfo, and also it's unusual to BakeCookie for
storage at qemu_driver.c. I've said this several days ago.
>
> >
> >
> > >
> > > 在 2012-11-15四的 10:04 +0800，liguang写道：
> > >> try to do non-shared migration without bothering to
> > >> create disk images at target by hand.
> > >>
> > >> consider this situation:
> > >> 1. non-shared migration
> > >> virsh migrate --copy-storage-all ...
> > >> 2. migration fails
> > >> 3. create disk images required
> > >> qemu-img create ...
> > >> 4 migration run smoothly
> > >> so, try do remove step 2, 3, 4
> > >>
> > >> this kind of usage had been discussed before,
> > >> http://www.redhat.com/archives/libvir-list/2011-December/msg00451.html
> > >>
> > >> this patch depends on my support offline migration patch:
> > >> https://www.redhat.com/archives/libvir-list/2012-November/msg00512.html
> > >>
> > >> Signed-off-by: liguang
> > >> ---
> > >> src/qemu/qemu_migration.c | 285
> > >> -
> > >> 1 files changed, 284 insertions(+), 1 deletions(-)
> > >>
> > >> diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> > >> index 54359c3..9e7ee4f 100644
> > >> --- a/src/qemu/qemu_migration.c
> > >> +++ b/src/qemu/qemu_migration.c
> > >> @@ -50,6 +50,7 @@
> > >> #include "storage_file.h"
> > >> #include "viruri.h"
> > >> #include "hooks.h"
> > >> +#include "dirname.h"
> > >>
> > >>
> > >> #define VIR_FROM_THIS VIR_FROM_QEMU
> > >> @@ -72,6 +73,7 @@ enum qemuMigrationCookieFlags {
> > >> QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE,
> > >> QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT,
> > >> QEMU_MIGRATION_COOKIE_FLAG_NETWORK,
> > >> +QEMU_MIGRATION_COOKIE_FLAG_COPYSTORAGE,
> > >>
> > >> QEMU_MIGRATION_COOKIE_FLAG_LAST
> > >> };
> > >> @@ -79,13 +81,14 @@ enum qemuMigrationCookieFlags {
> > >> VIR_ENUM_DECL(qemuMigrationCookieFlag);
> > >> VIR_ENUM_IMPL(qemuMigrationCookieFlag,
> > >> QEMU_MIGRATION_COOKIE_FLAG_LAST,
> > >> - "graphics", "lockstate", "persistent", "network");
> > >> + "graphics", "lockstate", "persistent", "network",
> > >> "storage");
> > >>
> > >> enum qemuMigrationCookieFeatures {
> > >> QEMU_MIGRATION_COOKIE_GRAPHICS = (1 <<
> > >> QEMU_MIGRATION_COOKIE_FLAG_GRAPHICS),
> > >> QEMU_MIGRATION_COOKIE_LOCKSTATE = (1 <<
> > >> QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE),
> > >> QEMU_MIGRATION_COOKIE_PERSISTENT = (1 <<
> > >> QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT),
> > >> QEMU_MIGRATION_COOKIE_NETWORK = (1 <<
> > >> QEMU_MIGRATION_COOKIE_FLAG_NETWORK),
> > >> +QEMU_MIGRATION_COOKIE_COPYSTORAGE = (1 <<
> > >> QEMU_MIGRATION_COOKIE_FLAG_COPYSTORAGE),
> > >> };
> > >>
> > >> typedef struct _qemuMigrationCookieGraphics qemuMigrationCookieGraphics;
> > >> @@ -119,6 +122,19 @@ struct _qemuMigrationCookieNetwork {
> > >> qemuMigrationCookieNetDataPtr net;
> > >> };
> > >>
> > >> +typedef struct _qemuMigrationCookieStorageData
> > >> qemuMigrationCookieStorageData;
> > >> +typedef qemuMigrationCookieStorageData
> > >> *qemuMigrationCookieStorageDataPtr
Re: [libvirt] [PATCH v1 2/2] help to create disk images of non-shared migration
在 2012-11-21三的 23:21 -0600，Doug Goldstein写道：
> On Nov 21, 2012, at 8:14 PM, li guang wrote:
>
> > ping ...
>
> The last review I asked that you drop the usage of qemu-img and use libvirt's
> block APIs and extend them as necessary to make it easier to call it.
> Otherwise you are duplicating functionality, not respecting the probe option,
> and only supporting file types supported by qemu-img.
yes, I'm considering your opinion,
but, seems it's not so convenience to use that function, you know?
or do you have a suitable way to call it during MigrationPrepareAny?
>
>
> >
> > 在 2012-11-15四的 10:04 +0800，liguang写道：
> >> try to do non-shared migration without bothering to
> >> create disk images at target by hand.
> >>
> >> consider this situation:
> >> 1. non-shared migration
> >> virsh migrate --copy-storage-all ...
> >> 2. migration fails
> >> 3. create disk images required
> >> qemu-img create ...
> >> 4 migration run smoothly
> >> so, try do remove step 2, 3, 4
> >>
> >> this kind of usage had been discussed before,
> >> http://www.redhat.com/archives/libvir-list/2011-December/msg00451.html
> >>
> >> this patch depends on my support offline migration patch:
> >> https://www.redhat.com/archives/libvir-list/2012-November/msg00512.html
> >>
> >> Signed-off-by: liguang
> >> ---
> >> src/qemu/qemu_migration.c | 285
> >> -
> >> 1 files changed, 284 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> >> index 54359c3..9e7ee4f 100644
> >> --- a/src/qemu/qemu_migration.c
> >> +++ b/src/qemu/qemu_migration.c
> >> @@ -50,6 +50,7 @@
> >> #include "storage_file.h"
> >> #include "viruri.h"
> >> #include "hooks.h"
> >> +#include "dirname.h"
> >>
> >>
> >> #define VIR_FROM_THIS VIR_FROM_QEMU
> >> @@ -72,6 +73,7 @@ enum qemuMigrationCookieFlags {
> >> QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE,
> >> QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT,
> >> QEMU_MIGRATION_COOKIE_FLAG_NETWORK,
> >> +QEMU_MIGRATION_COOKIE_FLAG_COPYSTORAGE,
> >>
> >> QEMU_MIGRATION_COOKIE_FLAG_LAST
> >> };
> >> @@ -79,13 +81,14 @@ enum qemuMigrationCookieFlags {
> >> VIR_ENUM_DECL(qemuMigrationCookieFlag);
> >> VIR_ENUM_IMPL(qemuMigrationCookieFlag,
> >> QEMU_MIGRATION_COOKIE_FLAG_LAST,
> >> - "graphics", "lockstate", "persistent", "network");
> >> + "graphics", "lockstate", "persistent", "network",
> >> "storage");
> >>
> >> enum qemuMigrationCookieFeatures {
> >> QEMU_MIGRATION_COOKIE_GRAPHICS = (1 <<
> >> QEMU_MIGRATION_COOKIE_FLAG_GRAPHICS),
> >> QEMU_MIGRATION_COOKIE_LOCKSTATE = (1 <<
> >> QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE),
> >> QEMU_MIGRATION_COOKIE_PERSISTENT = (1 <<
> >> QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT),
> >> QEMU_MIGRATION_COOKIE_NETWORK = (1 <<
> >> QEMU_MIGRATION_COOKIE_FLAG_NETWORK),
> >> +QEMU_MIGRATION_COOKIE_COPYSTORAGE = (1 <<
> >> QEMU_MIGRATION_COOKIE_FLAG_COPYSTORAGE),
> >> };
> >>
> >> typedef struct _qemuMigrationCookieGraphics qemuMigrationCookieGraphics;
> >> @@ -119,6 +122,19 @@ struct _qemuMigrationCookieNetwork {
> >> qemuMigrationCookieNetDataPtr net;
> >> };
> >>
> >> +typedef struct _qemuMigrationCookieStorageData
> >> qemuMigrationCookieStorageData;
> >> +typedef qemuMigrationCookieStorageData *qemuMigrationCookieStorageDataPtr;
> >> +struct _qemuMigrationCookieStorageData {
> >> +char *dsize;
> >> +};
> >> +
> >> +typedef struct _qemuMigrationCookieStorage qemuMigrationCookieStorage;
> >> +typedef qemuMigrationCookieStorage *qemuMigrationCookieStoragePtr;
> >> +struct _qemuMigrationCookieStorage {
> >> +int ndisks;
> >> +qemuMigrationCookieStorageDataPtr disk;
> >> +};
> >> +
> >> typedef struct _qemuMigrationCookie qemuMigrationCookie;
> >> typedef qemuMigrationCookie *qemuMigrationCookiePtr;
> >> struct _qemuMigrationCookie {
> >> @@ -147,6 +163,9 @@ struct _qemuMigrationCookie {
> >>
Re: [libvirt] [PATCH v1 2/2] help to create disk images of non-shared migration
;))
> +continue;
> +if (def->disks[i]->format < VIR_STORAGE_FILE_RAW)
> +goto error;
> +if (def->disks[i]->format >= VIR_STORAGE_FILE_LAST)
> +goto error;
> +
> +if (gen) {
> +char *dsize = mig->storage->disk[i].dsize;
> +cmd = virCommandNewArgList(img_tool, "create", "-f",
> + disk_format[def->disks[i]->format],
> + def->disks[i]->src, NULL);
> +virCommandAddArgFormat(cmd, "%s", dsize);
> +if (def->disks[i]->encryption)
> +virCommandAddArgList(cmd, "-o", "encryption=on", NULL);
> +virCommandSetOutputBuffer(cmd, &outbuf);
> +if (virCommandRun(cmd, NULL) < 0) {
> +virReportSystemError(errno, "%s", outbuf);
> + goto cleanup;
> +}
> +} else {
> +if (unlink(def->disks[i]->src) < 0) {
> +virReportError(errno, "%s", _("fail to unlink disk image
> file"));
> +goto cleanup;
> +}
> +}
> +virCommandFree(cmd);
> +VIR_FREE(tmp_dir);
> +VIR_FREE(outbuf);
> +}
> +
> +ret = 0;
> +
> +cleanup:
> +if (ret < 0) {
> +virCommandFree(cmd);
> +VIR_FREE(tmp_dir);
> +VIR_FREE(outbuf);
> +}
> +error:
> +return ret;
> +}
> +
> +
> /* Prepare is the first step, and it runs on the destination host.
> */
>
> @@ -1599,6 +1867,15 @@ qemuMigrationPrepareAny(struct qemud_driver *driver,
> /* virDomainAssignDef already set the error */
> goto cleanup;
> }
> +
> +if (!(mig = qemuMigrationEatCookie(driver, vm, cookiein, cookieinlen,
> + QEMU_MIGRATION_COOKIE_COPYSTORAGE)))
> +goto cleanup;
> +
> +if (flags & (VIR_MIGRATE_NON_SHARED_DISK | VIR_MIGRATE_NON_SHARED_INC))
> +if (qemuMigrationHandleDiskFiles(driver, def, true, mig) < 0)
> +goto endjob;
> +
> def = NULL;
> priv = vm->privateData;
> priv->origname = origname;
> @@ -3250,6 +3527,7 @@ qemuMigrationFinish(struct qemud_driver *driver,
> virErrorPtr orig_err = NULL;
> int cookie_flags = 0;
> qemuDomainObjPrivatePtr priv = vm->privateData;
> +bool migration_status = false;
>
> VIR_DEBUG("driver=%p, dconn=%p, vm=%p, cookiein=%s, cookieinlen=%d, "
>"cookieout=%p, cookieoutlen=%p, flags=%lx, retcode=%d",
> @@ -3415,7 +3693,12 @@ qemuMigrationFinish(struct qemud_driver *driver,
> if (qemuMigrationBakeCookie(mig, driver, vm, cookieout, cookieoutlen, 0)
> < 0)
> VIR_WARN("Unable to encode migration cookie");
>
> +migration_status = true;
> +
> endjob:
> +if (!migration_status && flags &
> +(VIR_MIGRATE_NON_SHARED_DISK | VIR_MIGRATE_NON_SHARED_INC))
> +qemuMigrationHandleDiskFiles(driver, vm->def, false, NULL);
> if (qemuMigrationJobFinish(driver, vm) == 0) {
> vm = NULL;
> } else if (!vm->persistent && !virDomainObjIsActive(vm)) {
--
li guang lig.f...@cn.fujitsu.com
linux kernel team at FNST, china
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v14] support offline migration
在 2012-11-19一的 10:05 +0800，li guang写道：
> 在 2012-11-16五的 13:59 +0100，Jiri Denemark写道：
> > On Mon, Nov 12, 2012 at 09:57:29 +0800, liguang wrote:
> > > original migration did not aware of offline case,
> > > so, try to support offline migration quietly
> > > (did not disturb original migration) by pass
> > > VIR_MIGRATE_OFFLINE flag to migration APIs if only
> > > the domain is really inactive, and
> > > migration process will not puzzled by domain
> > > offline and exit unexpectedly.
> > > these changes did not take care of disk images the
> > > domain required, for them could be transferred by
> > > other APIs as suggested, then VIR_MIGRATE_OFFLINE
> > > must not combined with VIR_MIGRATE_NON_SHARED_*.
> > > and you must do a persistent migration at same time,
> > > do "virsh migrate --offline --persistent ...".
> > >
> > > Signed-off-by: liguang
> > > ---
> > > include/libvirt/libvirt.h.in |1 +
> > > src/qemu/qemu_driver.c | 16 +++---
> > > src/qemu/qemu_migration.c| 110
> > > --
> > > src/qemu/qemu_migration.h|9 ++-
> > > tools/virsh-domain.c |5 ++
> > > tools/virsh.pod |5 +-
> > > 6 files changed, 97 insertions(+), 49 deletions(-)
> > >
> > > diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
> > > index fe58c08..1e0500d 100644
> > > --- a/include/libvirt/libvirt.h.in
> > > +++ b/include/libvirt/libvirt.h.in
> > > @@ -1090,6 +1090,7 @@ typedef enum {
> > > * whole migration
> > > process; this will be used automatically
> > > * when supported */
> > > VIR_MIGRATE_UNSAFE= (1 << 9), /* force migration even if
> > > it is considered unsafe */
> > > +VIR_MIGRATE_OFFLINE = (1 << 10), /* offline migrate */
> > > } virDomainMigrateFlags;
> > >
> > > /* Domain migration. */
> > > diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> > > index 978af57..5f91688 100644
> > > --- a/src/qemu/qemu_driver.c
> > > +++ b/src/qemu/qemu_driver.c
> > > @@ -9594,7 +9594,7 @@ qemudDomainMigratePrepareTunnel(virConnectPtr dconn,
> > >
> > > ret = qemuMigrationPrepareTunnel(driver, dconn,
> > > NULL, 0, NULL, NULL, /* No cookies
> > > in v2 */
> > > - st, dname, dom_xml);
> > > + st, dname, dom_xml, flags);
> > >
> > > cleanup:
> > > qemuDriverUnlock(driver);
> > > @@ -9654,7 +9654,7 @@ qemudDomainMigratePrepare2(virConnectPtr dconn,
> > > ret = qemuMigrationPrepareDirect(driver, dconn,
> > > NULL, 0, NULL, NULL, /* No cookies
> > > */
> > > uri_in, uri_out,
> > > - dname, dom_xml);
> > > + dname, dom_xml, flags);
> > >
> > > cleanup:
> > > qemuDriverUnlock(driver);
> > > @@ -9796,7 +9796,7 @@ qemuDomainMigrateBegin3(virDomainPtr domain,
> > > asyncJob = QEMU_ASYNC_JOB_NONE;
> > > }
> > >
> > > -if (!virDomainObjIsActive(vm)) {
> > > +if (!virDomainObjIsActive(vm) && !(flags & VIR_MIGRATE_OFFLINE)) {
> > > virReportError(VIR_ERR_OPERATION_INVALID,
> > > "%s", _("domain is not running"));
> > > goto endjob;
> > > @@ -9805,9 +9805,9 @@ qemuDomainMigrateBegin3(virDomainPtr domain,
> > > /* Check if there is any ejected media.
> > > * We don't want to require them on the destination.
> > > */
> > > -
> > > -if (qemuDomainCheckEjectableMedia(driver, vm, asyncJob) < 0)
> > > -goto endjob;
> > > +if (virDomainObjIsActive(vm) && (flags & VIR_MIGRATE_OFFLINE))
> > > +if (qemuDomainCheckEjectableMedia(driver, vm, asyncJob) < 0)
> > > +goto endjob;
> >
> > This condition is wrong, you actually want to call
> > qemuDomainCheckEjectableMedia iff the migration is NOT offline and in that
> > case we already know the dom
Re: [libvirt] [PATCH v14] support offline migration
omainMigrateOPDRelocate(driver, vm, mig) < 0)
> > +VIR_WARN("unable to provide network data for
> > relocation");
> > }
> >
> > -if (mig->network)
> > -if (qemuDomainMigrateOPDRelocate(driver, vm, mig) < 0)
> > -VIR_WARN("unable to provide network data for relocation");
> > -
> > if (flags & VIR_MIGRATE_PERSIST_DEST) {
> > virDomainDefPtr vmdef;
> > if (vm->persistent)
> > @@ -3302,7 +3334,7 @@ qemuMigrationFinish(struct qemud_driver *driver,
> > event = NULL;
> > }
> >
> > -if (!(flags & VIR_MIGRATE_PAUSED)) {
> > +if (!(flags & VIR_MIGRATE_PAUSED) && !(flags &
> > VIR_MIGRATE_OFFLINE)) {
> > /* run 'cont' on the destination, which allows migration on
> > qemu
> > * >= 0.10.6 to work properly. This isn't strictly necessary
> > on
> > * older qemu's, but it also doesn't hurt anything there
> > @@ -3351,9 +3383,11 @@ qemuMigrationFinish(struct qemud_driver *driver,
> > VIR_DOMAIN_EVENT_SUSPENDED,
> >
> > VIR_DOMAIN_EVENT_SUSPENDED_PAUSED);
> > }
> > -if (virDomainSaveStatus(driver->caps, driver->stateDir, vm) < 0) {
> > -VIR_WARN("Failed to save status on vm %s", vm->def->name);
> > -goto endjob;
> > +if (virDomainObjIsActive(vm)) {
> > +if (virDomainSaveStatus(driver->caps, driver->stateDir, vm) <
> > 0) {
> > +VIR_WARN("Failed to save status on vm %s", vm->def->name);
> > +goto endjob;
> > +}
> > }
>
> We should also skip generating the events. Or even better, we should emit
> VIR_DOMAIN_EVENT_DEFINED for offline migration.
Okay, I will skip.
>
> >
> > /* Guest is successfully running, so cancel previous auto destroy
> > */
> > @@ -3420,6 +3454,9 @@ int qemuMigrationConfirm(struct qemud_driver *driver,
> > if (!(mig = qemuMigrationEatCookie(driver, vm, cookiein, cookieinlen,
> > 0)))
> > return -1;
> >
> > +if (flags & VIR_MIGRATE_OFFLINE)
> > +goto done;
> > +
> > /* Did the migration go as planned? If yes, kill off the
> > * domain object, but if no, resume CPUs
> > */
> > @@ -3455,6 +3492,7 @@ int qemuMigrationConfirm(struct qemud_driver *driver,
> > }
> > }
> >
> > +done:
> > qemuMigrationCookieFree(mig);
> > rv = 0;
> >
> > diff --git a/src/qemu/qemu_migration.h b/src/qemu/qemu_migration.h
> > index 7a2269a..f2dc5aa 100644
> > --- a/src/qemu/qemu_migration.h
> > +++ b/src/qemu/qemu_migration.h
> > @@ -36,7 +36,8 @@
> > VIR_MIGRATE_NON_SHARED_DISK | \
> > VIR_MIGRATE_NON_SHARED_INC | \
> > VIR_MIGRATE_CHANGE_PROTECTION |\
> > - VIR_MIGRATE_UNSAFE)
> > + VIR_MIGRATE_UNSAFE | \
> > + VIR_MIGRATE_OFFLINE)
> >
> > enum qemuMigrationJobPhase {
> > QEMU_MIGRATION_PHASE_NONE = 0,
> > @@ -97,7 +98,8 @@ int qemuMigrationPrepareTunnel(struct qemud_driver
> > *driver,
> > int *cookieoutlen,
> > virStreamPtr st,
> > const char *dname,
> > - const char *dom_xml);
> > + const char *dom_xml,
> > + unsigned long flags);
> >
> > int qemuMigrationPrepareDirect(struct qemud_driver *driver,
> > virConnectPtr dconn,
> > @@ -108,7 +110,8 @@ int qemuMigrationPrepareDirect(struct qemud_driver
> > *driver,
> > const char *uri_in,
> > char **uri_out,
> > const char *dname,
> > - const char *dom_xml);
> > + const char *dom_xml,
> > + unsigned long flags);
> >
> > int qemuMigrationPerform(struct qemud_driver *driver,
> > virConnectPtr conn,
> > diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
> > index 393b67b..39674ba 100644
> > --- a/tools/virsh-domain.c
> > +++ b/tools/virsh-domain.c
> > @@ -6644,6 +6644,7 @@ static const vshCmdInfo info_migrate[] = {
> >
> > static const vshCmdOptDef opts_migrate[] = {
> > {"live", VSH_OT_BOOL, 0, N_("live migration")},
> > +{"offline", VSH_OT_BOOL, 0, N_("offline (domain's inactive)
> > migration")},
> > {"p2p", VSH_OT_BOOL, 0, N_("peer-2-peer migration")},
> > {"direct", VSH_OT_BOOL, 0, N_("direct migration")},
> > {"tunneled", VSH_OT_ALIAS, 0, "tunnelled"},
> > @@ -6729,6 +6730,10 @@ doMigrate(void *opaque)
> > if (vshCommandOptBool(cmd, "unsafe"))
> > flags |= VIR_MIGRATE_UNSAFE;
> >
> > +if (vshCommandOptBool(cmd, "offline")) {
> > +flags |= VIR_MIGRATE_OFFLINE;
> > +}
> > +
> > if (xmlfile &&
> > virFileReadAll(xmlfile, 8192, &xml) < 0) {
> > vshError(ctl, _("file '%s' doesn't exist"), xmlfile);
> > diff --git a/tools/virsh.pod b/tools/virsh.pod
> > index e0c6b42..2545455 100644
> > --- a/tools/virsh.pod
> > +++ b/tools/virsh.pod
> > @@ -1026,13 +1026,14 @@ I<--total> for only the total stats, I for
> > only the per-cpu
> > stats of the CPUs from I, I for only I CPUs'
> > stats.
> >
> > -=item B [I<--live>] [I<--direct>] [I<--p2p> [I<--tunnelled>]]
> > +=item B [I<--live>] [I<--offline>] [I<--direct>] [I<--p2p>
> > [I<--tunnelled>]]
> > [I<--persistent>] [I<--undefinesource>] [I<--suspend>]
> > [I<--copy-storage-all>]
> > [I<--copy-storage-inc>] [I<--change-protection>] [I<--unsafe>]
> > [I<--verbose>]
> > I I [I] [I]
> > [I<--timeout> B] [I<--xml> B]
> >
> > -Migrate domain to another host. Add I<--live> for live migration; I<--p2p>
> > +Migrate domain to another host. Add I<--live> for live migration;
> > +I<--offline> for offline (domain's inactive) migration; <--p2p>
> > for peer-2-peer migration; I<--direct> for direct migration; or
> > I<--tunnelled>
> > for tunnelled migration. I<--persistent> leaves the domain persistent on
> > destination host, I<--undefinesource> undefines the domain on the source
> > host,
>
> I'm afraid we need yet another version of this patch :-(
Okay, Thanks for your kind comment!
>
> Jirka
--
li guang lig.f...@cn.fujitsu.com
linux kernel team at FNST, china
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v13] support offline migration
在 2012-11-16五的 11:21 +0100，Jiri Denemark写道： > On Mon, Nov 12, 2012 at 09:26:30 +0800, li guang wrote: > > 在 2012-11-09五的 13:00 +0100，Jiri Denemark写道： > > > On Fri, Nov 09, 2012 at 10:57:23 +0800, li guang wrote: > > > > > > Well, and that's the thing that actually needs fixing. The migration code > > > in > > > libvirt.c and the code doing peer-to-peer migration in qemu_migration.c > > > are > > > very similar because they are doing almost the same job (only at different > > > levels). It makes sense to change them both at the same time. Why do you > > > want > > > to avoid changing code in libvirt.c? > > > > first, I think it's clean enough for my patch to do offline migration, > > second, someone told me to keep public API stability of libvirt > > before(it's not clear who and when), so I fear to change. > > Well, don't worry I'm aware of API/ABI stability we need to maintain in > libvirt and I wouldn't suggest you to do something that would break anything > in that area. Of course you can't add new parameters to existing public > functions, for example. But changing the code inside to support new flags is > allowed. > Okay. > > you mean I should take care of fixing or re-factoring redundant code > > this time? maybe I can try to do something after this patch. > > No. It's just that the migration code in libvirt.c and the p2p code in > qemu_migration.c are very similar since they are doing the same thing at > different levels. You can't really refactor that and I'm not asking you to do > so. However, since the code logic is similar in both places, it's wise to keep > it that way and just skip Perform phase for offline migrations regardless on > the actual type of migration. I'd much like to see that rather than hacking > somewhere inside the code doing Perform phase to exit if it notices it should > not have been run at all. > > Jirka -- li guang lig.f...@cn.fujitsu.com linux kernel team at FNST, china -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] beautify code indent in qemu migration
在 2012-11-16五的 12:51 +0800，Osier Yang写道：
> On 2012年11月16日 11:27, liguang wrote:
> > Signed-off-by: liguang
> > ---
> > src/qemu/qemu_migration.c | 18 ++
> > 1 files changed, 6 insertions(+), 12 deletions(-)
> >
> > diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> > index 716365f..0e00cac 100644
> > --- a/src/qemu/qemu_migration.c
> > +++ b/src/qemu/qemu_migration.c
> > @@ -692,12 +692,10 @@ qemuMigrationCookieXMLFormat(struct qemud_driver
> > *driver,
> > qemuMigrationCookieFlagTypeToString(i));
> > }
> >
> > -if ((mig->flags& QEMU_MIGRATION_COOKIE_GRAPHICS)&&
> > -mig->graphics)
> > +if ((mig->flags& QEMU_MIGRATION_COOKIE_GRAPHICS)&& mig->graphics)
> > qemuMigrationCookieGraphicsXMLFormat(buf, mig->graphics);
>
> Things like this is really personal favor I think.
it's clear that "if statement" can be placed one line,
why a new line is acceptable?
don't you think it's more beautiful and tidier?
> >
> > -if ((mig->flags& QEMU_MIGRATION_COOKIE_LOCKSTATE)&&
> > -mig->lockState) {
> > +if ((mig->flags& QEMU_MIGRATION_COOKIE_LOCKSTATE)&& mig->lockState) {
> > virBufferAsprintf(buf, "\n",
> > mig->lockDriver);
> > virBufferAsprintf(buf, "%s\n",
> > @@ -705,8 +703,7 @@ qemuMigrationCookieXMLFormat(struct qemud_driver
> > *driver,
> > virBufferAddLit(buf, "\n");
> > }
> >
> > -if ((mig->flags& QEMU_MIGRATION_COOKIE_PERSISTENT)&&
> > -mig->persistent) {
> > +if ((mig->flags& QEMU_MIGRATION_COOKIE_PERSISTENT)&&
> > mig->persistent) {
> > virBufferAdjustIndent(buf, 2);
> > if (qemuDomainDefFormatBuf(driver,
> > mig->persistent,
> > @@ -790,7 +787,6 @@ qemuMigrationCookieGraphicsXMLParse(xmlXPathContextPtr
> > ctxt)
> > /* Optional */
> > grap->tlsSubject =
> > virXPathString("string(./graphics/cert[@info='subject']/@value)", ctxt);
> >
> > -
>
> This is good though.
>
> > return grap;
> >
> > no_memory:
> > @@ -821,7 +817,7 @@ qemuMigrationCookieNetworkXMLParse(xmlXPathContextPtr
> > ctxt)
> > }
> >
> > optr->nnets = n;
> > -if (VIR_ALLOC_N(optr->net, optr->nnets)<0)
> > +if (VIR_ALLOC_N(optr->net, optr->nnets)< 0)
>
> Good too.
>
> > goto no_memory;
> >
> > for (i = 0; i< n; i++) {
> > @@ -1137,8 +1133,7 @@ qemuMigrationEatCookie(struct qemud_driver *driver,
> > qemuMigrationCookiePtr mig = NULL;
> >
> > /* Parse& validate incoming cookie (if any) */
> > -if (cookiein&& cookieinlen&&
> > -cookiein[cookieinlen-1] != '\0') {
> > +if (cookiein&& cookieinlen&& cookiein[cookieinlen-1] != '\0') {
> > virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> > _("Migration cookie was not NULL terminated"));
> > goto error;
> > @@ -1204,8 +1199,7 @@ qemuMigrationIsAllowed(struct qemud_driver *driver,
> > virDomainObjPtr vm,
> > "%s", _("domain is marked for auto destroy"));
> > return false;
> > }
> > -if ((nsnapshots = virDomainSnapshotObjListNum(vm->snapshots, NULL,
> > - 0))) {
> > +if ((nsnapshots = virDomainSnapshotObjListNum(vm->snapshots, NULL,
> > 0))) {
>
> More than 80 chars.
74 chars
> > virReportError(VIR_ERR_OPERATION_INVALID,
> > _("cannot migrate domain with %d snapshots"),
> > nsnapshots);
>
>
> Regards,
> Osier
--
li guang lig.f...@cn.fujitsu.com
linux kernel team at FNST, china
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v14] support offline migration
gt; +if (qemuDomainMigrateOPDRelocate(driver, vm, mig) < 0)
> +VIR_WARN("unable to provide network data for
> relocation");
> }
>
> -if (mig->network)
> -if (qemuDomainMigrateOPDRelocate(driver, vm, mig) < 0)
> -VIR_WARN("unable to provide network data for relocation");
> -
> if (flags & VIR_MIGRATE_PERSIST_DEST) {
> virDomainDefPtr vmdef;
> if (vm->persistent)
> @@ -3302,7 +3334,7 @@ qemuMigrationFinish(struct qemud_driver *driver,
> event = NULL;
> }
>
> -if (!(flags & VIR_MIGRATE_PAUSED)) {
> +if (!(flags & VIR_MIGRATE_PAUSED) && !(flags & VIR_MIGRATE_OFFLINE))
> {
> /* run 'cont' on the destination, which allows migration on qemu
> * >= 0.10.6 to work properly. This isn't strictly necessary on
> * older qemu's, but it also doesn't hurt anything there
> @@ -3351,9 +3383,11 @@ qemuMigrationFinish(struct qemud_driver *driver,
> VIR_DOMAIN_EVENT_SUSPENDED,
>
> VIR_DOMAIN_EVENT_SUSPENDED_PAUSED);
> }
> -if (virDomainSaveStatus(driver->caps, driver->stateDir, vm) < 0) {
> -VIR_WARN("Failed to save status on vm %s", vm->def->name);
> -goto endjob;
> +if (virDomainObjIsActive(vm)) {
> +if (virDomainSaveStatus(driver->caps, driver->stateDir, vm) < 0)
> {
> +VIR_WARN("Failed to save status on vm %s", vm->def->name);
> +goto endjob;
> +}
> }
>
> /* Guest is successfully running, so cancel previous auto destroy */
> @@ -3420,6 +3454,9 @@ int qemuMigrationConfirm(struct qemud_driver *driver,
> if (!(mig = qemuMigrationEatCookie(driver, vm, cookiein, cookieinlen,
> 0)))
> return -1;
>
> +if (flags & VIR_MIGRATE_OFFLINE)
> +goto done;
> +
> /* Did the migration go as planned? If yes, kill off the
> * domain object, but if no, resume CPUs
> */
> @@ -3455,6 +3492,7 @@ int qemuMigrationConfirm(struct qemud_driver *driver,
> }
> }
>
> +done:
> qemuMigrationCookieFree(mig);
> rv = 0;
>
> diff --git a/src/qemu/qemu_migration.h b/src/qemu/qemu_migration.h
> index 7a2269a..f2dc5aa 100644
> --- a/src/qemu/qemu_migration.h
> +++ b/src/qemu/qemu_migration.h
> @@ -36,7 +36,8 @@
> VIR_MIGRATE_NON_SHARED_DISK | \
> VIR_MIGRATE_NON_SHARED_INC | \
> VIR_MIGRATE_CHANGE_PROTECTION |\
> - VIR_MIGRATE_UNSAFE)
> + VIR_MIGRATE_UNSAFE | \
> + VIR_MIGRATE_OFFLINE)
>
> enum qemuMigrationJobPhase {
> QEMU_MIGRATION_PHASE_NONE = 0,
> @@ -97,7 +98,8 @@ int qemuMigrationPrepareTunnel(struct qemud_driver *driver,
> int *cookieoutlen,
> virStreamPtr st,
> const char *dname,
> - const char *dom_xml);
> + const char *dom_xml,
> + unsigned long flags);
>
> int qemuMigrationPrepareDirect(struct qemud_driver *driver,
> virConnectPtr dconn,
> @@ -108,7 +110,8 @@ int qemuMigrationPrepareDirect(struct qemud_driver
> *driver,
> const char *uri_in,
> char **uri_out,
> const char *dname,
> - const char *dom_xml);
> + const char *dom_xml,
> + unsigned long flags);
>
> int qemuMigrationPerform(struct qemud_driver *driver,
> virConnectPtr conn,
> diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
> index 393b67b..39674ba 100644
> --- a/tools/virsh-domain.c
> +++ b/tools/virsh-domain.c
> @@ -6644,6 +6644,7 @@ static const vshCmdInfo info_migrate[] = {
>
> static const vshCmdOptDef opts_migrate[] = {
> {"live", VSH_OT_BOOL, 0, N_("live migration")},
> +{"offline", VSH_OT_BOOL, 0, N_("offline (domain's inactive) migration")},
> {"p2p", VSH_OT_BOOL, 0, N_("peer-2-peer migration")},
> {"direct", VSH_OT_BOOL, 0, N_("direct migration")},
> {"tunneled", VSH_OT_ALIAS, 0, "tunnelled"},
> @@ -6729,6 +6730,10 @@ doMigrate(void *opaque)
> if (vshCommandOptBool(cmd, "unsafe"))
> flags |= VIR_MIGRATE_UNSAFE;
>
> +if (vshCommandOptBool(cmd, "offline")) {
> +flags |= VIR_MIGRATE_OFFLINE;
> +}
> +
> if (xmlfile &&
> virFileReadAll(xmlfile, 8192, &xml) < 0) {
> vshError(ctl, _("file '%s' doesn't exist"), xmlfile);
> diff --git a/tools/virsh.pod b/tools/virsh.pod
> index e0c6b42..2545455 100644
> --- a/tools/virsh.pod
> +++ b/tools/virsh.pod
> @@ -1026,13 +1026,14 @@ I<--total> for only the total stats, I for
> only the per-cpu
> stats of the CPUs from I, I for only I CPUs'
> stats.
>
> -=item B [I<--live>] [I<--direct>] [I<--p2p> [I<--tunnelled>]]
> +=item B [I<--live>] [I<--offline>] [I<--direct>] [I<--p2p>
> [I<--tunnelled>]]
> [I<--persistent>] [I<--undefinesource>] [I<--suspend>]
> [I<--copy-storage-all>]
> [I<--copy-storage-inc>] [I<--change-protection>] [I<--unsafe>] [I<--verbose>]
> I I [I] [I]
> [I<--timeout> B] [I<--xml> B]
>
> -Migrate domain to another host. Add I<--live> for live migration; I<--p2p>
> +Migrate domain to another host. Add I<--live> for live migration;
> +I<--offline> for offline (domain's inactive) migration; <--p2p>
> for peer-2-peer migration; I<--direct> for direct migration; or
> I<--tunnelled>
> for tunnelled migration. I<--persistent> leaves the domain persistent on
> destination host, I<--undefinesource> undefines the domain on the source
> host,
--
li guang lig.f...@cn.fujitsu.com
linux kernel team at FNST, china
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v1 2/2] help to create disk images of non-shared migration
const char *disk_format[] = {"none", "raw", "none", "none", "none",
> > +"cow", "none", "none", "qcow", "qcow2",
> > +"qed", "vmdk", "vpc","none", "none"
> > +};
> > +virCommandPtr cmd = NULL;
> > +int i, ret = -1;
> > +
> > +if (!def->ndisks)
> > +return 0;
> > +
> > +if (img_tool == NULL) {
> > +virReportError(VIR_ERR_INTERNAL_ERROR,
> > + "%s", _("unable to find kvm-img or qemu-img"));
> > +goto error;
> > +}
> > +
> > +for (i = 0; i < def->ndisks; i++) {
> > +if (STRNEQ(def->disks[i]->driverName, "qemu"))
> > +continue;
> > +if (def->disks[i]->src == NULL)
> > +continue;
> > +if (virFileExists(def->disks[i]->src) && gen)
> > +continue;
> > +if (!gen && !virFileExists(def->disks[i]->src))
> > +continue;
> > +if ((tmp_dir = mdir_name(def->disks[i]->src)) == NULL)
> > +continue;
> > +if (!virFileExists(tmp_dir))
> > +if (virFileMakePath(tmp_dir) < 0)
> > +continue;
> > +if (STREQ(disk_format[def->disks[i]->format], "none"))
> > +continue;
> > +if (def->disks[i]->format < VIR_STORAGE_FILE_RAW)
> > +goto error;
> > +if (def->disks[i]->format >= VIR_STORAGE_FILE_LAST)
> > +goto error;
> > +
> > +if (gen) {
> > +char *dsize = mig->storage->disk[i].dsize;
> > +cmd = virCommandNewArgList(img_tool, "create", "-f",
> > + disk_format[def->disks[i]->format],
> > + def->disks[i]->src, NULL);
> > +virCommandAddArgFormat(cmd, "%s", dsize);
> > +if (def->disks[i]->encryption)
> > +virCommandAddArgList(cmd, "-o", "encryption=on", NULL);
> > +virCommandSetOutputBuffer(cmd, &outbuf);
> > +if (virCommandRun(cmd, NULL) < 0) {
> > +virReportSystemError(errno, "%s", outbuf);
> > +goto cleanup;
> > +}
> > +} else {
> > +if (unlink(def->disks[i]->src) < 0) {
> > +virReportError(errno, "%s", _("fail to unlink disk image
> > file"));
> > +goto cleanup;
> > +}
> > +}
> > +virCommandFree(cmd);
> > +VIR_FREE(tmp_dir);
> > +VIR_FREE(outbuf);
> > +}
> > +
> > +ret = 0;
> > +
> > +cleanup:
> > +if (ret < 0) {
> > +virCommandFree(cmd);
> > +VIR_FREE(tmp_dir);
> > +VIR_FREE(outbuf);
> > +}
> > +error:
> > +return ret;
> > +}
> > +
> > +
> > /* Prepare is the first step, and it runs on the destination host.
> > */
> >
> > @@ -1599,6 +1867,15 @@ qemuMigrationPrepareAny(struct qemud_driver *driver,
> > /* virDomainAssignDef already set the error */
> > goto cleanup;
> > }
> > +
> > +if (!(mig = qemuMigrationEatCookie(driver, vm, cookiein, cookieinlen,
> > + QEMU_MIGRATION_COOKIE_COPYSTORAGE)))
> > +goto cleanup;
> > +
> > +if (flags & (VIR_MIGRATE_NON_SHARED_DISK | VIR_MIGRATE_NON_SHARED_INC))
> > +if (qemuMigrationHandleDiskFiles(driver, def, true, mig) < 0)
> > +goto endjob;
> > +
> > def = NULL;
> > priv = vm->privateData;
> > priv->origname = origname;
> > @@ -3250,6 +3527,7 @@ qemuMigrationFinish(struct qemud_driver *driver,
> > virErrorPtr orig_err = NULL;
> > int cookie_flags = 0;
> > qemuDomainObjPrivatePtr priv = vm->privateData;
> > +bool migration_status = false;
> >
> > VIR_DEBUG("driver=%p, dconn=%p, vm=%p, cookiein=%s, cookieinlen=%d, "
> >"cookieout=%p, cookieoutlen=%p, flags=%lx, retcode=%d",
> > @@ -3415,7 +3693,12 @@ qemuMigrationFinish(struct qemud_driver *driver,
> > if (qemuMigrationBakeCookie(mig, driver, vm, cookieout, cookieoutlen,
> > 0) < 0)
> > VIR_WARN("Unable to encode migration cookie");
> >
> > +migration_status = true;
> > +
> > endjob:
> > +if (!migration_status && flags &
> > +(VIR_MIGRATE_NON_SHARED_DISK | VIR_MIGRATE_NON_SHARED_INC))
> > +qemuMigrationHandleDiskFiles(driver, vm->def, false, NULL);
> > if (qemuMigrationJobFinish(driver, vm) == 0) {
> > vm = NULL;
> > } else if (!vm->persistent && !virDomainObjIsActive(vm)) {
> > --
> > 1.7.1
> >
> > --
> > libvir-list mailing list
> > libvir-list@redhat.com
> > https://www.redhat.com/mailman/listinfo/libvir-list
>
>
>
--
li guang lig.f...@cn.fujitsu.com
linux kernel team at FNST, china
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/2] init qemu_driver's qemuImgBinary field
在 2012-11-14三的 07:07 -0700，Eric Blake写道： > On 11/14/2012 01:57 AM, li guang wrote: > > 在 2012-11-14三的 02:28 -0600，Doug Goldstein写道： > >> On Wed, Nov 14, 2012 at 1:56 AM, li guang wrote: > >>> 在 2012-11-14三的 01:38 -0600，Doug Goldstein写道： > >>>> On Tue, Nov 13, 2012 at 9:03 PM, liguang wrote: > >>>>> Signed-off-by: liguang > >>>>> --- > > Your commit message needs justification why you are moving from a lazy > cache to a guaranteed initialization. OK, will add more commit messages. > > >> > >> I would argue that its bad form to do that for at least 2 reasons. > >> 1. The fact that driver->qemuImgBinary is "hidden" behind a function > >> to access it means you should effectively treat it as opaque and not > >> directly access it. > > > > well, quite conceptually, > > but, qemu_driver is global variable, > > every member can't be hidden at all. > > e.g. driver->snapshotDir was used directly. > > I don't mind accessing the member variable directly, but only on > condition that we completely delete qemuFindQemuImgBinary(), and instead > inline its initialization code into the one-time initialization. As > long as the function call remains, then code should use the function > call. If you are trying to avoid the caching function call, then you > should avoid it everywhere, and this patch didn't go far enough. > will change further. -- li guang lig.f...@cn.fujitsu.com linux kernel team at FNST, china -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/2] init qemu_driver's qemuImgBinary field
在 2012-11-14三的 02:28 -0600，Doug Goldstein写道：
> On Wed, Nov 14, 2012 at 1:56 AM, li guang wrote:
> > 在 2012-11-14三的 01:38 -0600，Doug Goldstein写道：
> >> On Tue, Nov 13, 2012 at 9:03 PM, liguang wrote:
> >> > Signed-off-by: liguang
> >> > ---
> >> > src/qemu/qemu_domain.c |2 +-
> >> > src/qemu/qemu_driver.c |3 +++
> >> > 2 files changed, 4 insertions(+), 1 deletions(-)
> >> >
> >> > diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> >> > index a5592b9..eb5a3d1 100644
> >> > --- a/src/qemu/qemu_domain.c
> >> > +++ b/src/qemu/qemu_domain.c
> >> > @@ -1647,7 +1647,7 @@ qemuDomainSnapshotForEachQcow2Raw(struct
> >> > qemud_driver *driver,
> >> > int i;
> >> > bool skipped = false;
> >> >
> >> > -qemuimgarg[0] = qemuFindQemuImgBinary(driver);
> >> > +qemuimgarg[0] = driver->qemuImgBinary;
> >> > if (qemuimgarg[0] == NULL) {
> >> > /* qemuFindQemuImgBinary set the error */
> >> > return -1;
> >> > diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> >> > index 5f91688..a25fb53 100644
> >> > --- a/src/qemu/qemu_driver.c
> >> > +++ b/src/qemu/qemu_driver.c
> >> > @@ -626,6 +626,9 @@ qemudStartup(int privileged) {
> >> > if (!qemu_driver->domainEventState)
> >> > goto error;
> >> >
> >> > +/* find kvm-img or qemu-img */
> >> > +qemuFindQemuImgBinary(qemu_driver);
> >> > +
> >> > /* read the host sysinfo */
> >> > if (privileged)
> >> > qemu_driver->hostsysinfo = virSysinfoRead();
> >> > --
> >> > 1.7.1
> >> >
> >> > --
> >> > libvir-list mailing list
> >> > libvir-list@redhat.com
> >> > https://www.redhat.com/mailman/listinfo/libvir-list
> >>
> >> Honestly this entire patch can be dropped because its not correct.
> >> qemuFindQemuImgBinary() only looks up the path to the binary the first
> >> time and then caches it from there on in. So you should always be
> >> using qemuFindQemuImgBinary(). As far as the addition to the startup
> >> of looking it up, it seems like that's really a pre-mature
> >> optimization for your second patch.
> >>
> >> So I'd have to say NACK on this change.
> >>
> >
> > your reason sounds strange, you call qemuFindQemuImgBinary()
> > to get qemu-img handler every time you want to use it,
> > I use the handler freely for I've I've initialized before
> > why can't I use driver->qemuImgBinary instead of
> > qemuFindQemuImgBinary()?
> >
>
> I would argue that its bad form to do that for at least 2 reasons.
> 1. The fact that driver->qemuImgBinary is "hidden" behind a function
> to access it means you should effectively treat it as opaque and not
> directly access it.
well, quite conceptually,
but, qemu_driver is global variable,
every member can't be hidden at all.
e.g. driver->snapshotDir was used directly.
> 2. Its only found when its actually needed rather than always looking
> it up when libvirt starts up.
I just initialize it like other variables of qemu_driver,
e.g. libDir, cacheDir, saveDir, snapshotDir...
>
> qemuFindQemuImgBinary() is functionally equivalent to
> driver->qemuImgBinary after the first call.
>
--
li guang lig.f...@cn.fujitsu.com
linux kernel team at FNST, china
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/2] init qemu_driver's qemuImgBinary field
在 2012-11-14三的 01:38 -0600，Doug Goldstein写道：
> On Tue, Nov 13, 2012 at 9:03 PM, liguang wrote:
> > Signed-off-by: liguang
> > ---
> > src/qemu/qemu_domain.c |2 +-
> > src/qemu/qemu_driver.c |3 +++
> > 2 files changed, 4 insertions(+), 1 deletions(-)
> >
> > diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> > index a5592b9..eb5a3d1 100644
> > --- a/src/qemu/qemu_domain.c
> > +++ b/src/qemu/qemu_domain.c
> > @@ -1647,7 +1647,7 @@ qemuDomainSnapshotForEachQcow2Raw(struct qemud_driver
> > *driver,
> > int i;
> > bool skipped = false;
> >
> > -qemuimgarg[0] = qemuFindQemuImgBinary(driver);
> > +qemuimgarg[0] = driver->qemuImgBinary;
> > if (qemuimgarg[0] == NULL) {
> > /* qemuFindQemuImgBinary set the error */
> > return -1;
> > diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> > index 5f91688..a25fb53 100644
> > --- a/src/qemu/qemu_driver.c
> > +++ b/src/qemu/qemu_driver.c
> > @@ -626,6 +626,9 @@ qemudStartup(int privileged) {
> > if (!qemu_driver->domainEventState)
> > goto error;
> >
> > +/* find kvm-img or qemu-img */
> > +qemuFindQemuImgBinary(qemu_driver);
> > +
> > /* read the host sysinfo */
> > if (privileged)
> > qemu_driver->hostsysinfo = virSysinfoRead();
> > --
> > 1.7.1
> >
> > --
> > libvir-list mailing list
> > libvir-list@redhat.com
> > https://www.redhat.com/mailman/listinfo/libvir-list
>
> Honestly this entire patch can be dropped because its not correct.
> qemuFindQemuImgBinary() only looks up the path to the binary the first
> time and then caches it from there on in. So you should always be
> using qemuFindQemuImgBinary(). As far as the addition to the startup
> of looking it up, it seems like that's really a pre-mature
> optimization for your second patch.
>
> So I'd have to say NACK on this change.
>
your reason sounds strange, you call qemuFindQemuImgBinary()
to get qemu-img handler every time you want to use it,
I use the handler freely for I've I've initialized before
why can't I use driver->qemuImgBinary instead of
qemuFindQemuImgBinary()?
--
li guang lig.f...@cn.fujitsu.com
linux kernel team at FNST, china
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 1/2] helper of copy-storage-* features
在 2012-11-09五的 07:27 -0700，Eric Blake写道：
> On 11/08/2012 10:26 PM, li guang wrote:
>
> >>> +{
> >>> +char *tmp_dir = NULL, *outbuf = NULL;
> >>> +char *img_tool = driver->qemuImgBinary;
> >>
> >> Don't grab this field directly. Instead, use
> >> qemuFindQemuImgBinary(driver).
> >
> > driver->qemuImgBinary is useful, I've initiated it.
> > why don't we use it?
>
> In the order your series was written, driver->qemuImgBinary may be
> uninitialized. If you swap the order and put patch 2/2 first, then yes,
> you could use this field directly instead of calling
> qemuFindQemuImgBinary. You should always try to order your patches so
> that no patch is broken until later patches in the series have been applied.
>
> >>> +if (gen_del) {
> >>> +cmd = virCommandNewArgList(img_tool, "create", "-f",
> >>> + def->disks[i]->driverType,
> >>> def->disks[i]->src, NULL);
> >>> +if (STREQ(def->disks[i]->driverType, "qcow2") ||
> >>> +STREQ(def->disks[i]->driverType, "qcow"))
> >>> +virCommandAddArgFormat(cmd, "%lluK", 0xff);
> >>
> >> Ouch. You should not be passing in random sizes to qemu - if you need
> >> to know the source size in order to create a file on the destination
> >> side, then we HAVE to modify the migration cookie in order to pass
> >> sizing information when the new flag is present.
> >>
> >
> > passing by cookie seems a little rough,
> > these sizes are not random, they're
> > the max size of their format.
> > does setting max size hurt?
>
> Yes, because it is wrong.
>
> > the disk images are sparse files,
>
> So?
real size of disk image will not take much disk space.
> A user that calls virsh vol-info on the file on the destination
> side should not get infinite size, but the same size as they would get
> on the source. Just because it doesn't (yet) occupy the entire disk
> doesn't mean that we should size it so large that the file can grow
> without effective bounds and cause ENOSPC.
um, vol-info is a problem,
though it seems odd for me.
can we add size field to _virDomainDiskDef?
if be allowed, life will be easier.
>
> > and after qemu migration finished, size will be right.
>
> If qemu changes the size after migration, then why can't it change from
> 0 to the proper size, rather than from max to the proper size?
I mean the disk size not virtual size.
>
--
li guang lig.f...@cn.fujitsu.com
linux kernel team at FNST, china
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v13] support offline migration
在 2012-11-09五的 13:00 +0100，Jiri Denemark写道： > On Fri, Nov 09, 2012 at 10:57:23 +0800, li guang wrote: > ... > > > > @@ -2150,6 +2192,9 @@ qemuMigrationRun(struct qemud_driver *driver, > > > > return -1; > > > > } > > > > > > > > +if (flags & VIR_MIGRATE_OFFLINE) > > > > +return 0; > > > > + > > > > if (!(mig = qemuMigrationEatCookie(driver, vm, cookiein, > > > cookieinlen, > > > > > > > QEMU_MIGRATION_COOKIE_GRAPHICS))) > > > > goto cleanup; > > > > > > I still think we should not even get into qemuMigrationRun when doing > > > offline migration. > > > > No, it will get into here for I did not touch migrationPerform path, > > initially I don't want to change any code at libvirt.c so I must keep > > offline migration walk through whole path like normal, or there're maybe > > lots of fixes, any will break up the migration path. > > Well, and that's the thing that actually needs fixing. The migration code in > libvirt.c and the code doing peer-to-peer migration in qemu_migration.c are > very similar because they are doing almost the same job (only at different > levels). It makes sense to change them both at the same time. Why do you want > to avoid changing code in libvirt.c? first, I think it's clean enough for my patch to do offline migration, second, someone told me to keep public API stability of libvirt before(it's not clear who and when), so I fear to change. you mean I should take care of fixing or re-factoring redundant code this time? maybe I can try to do something after this patch. > > Jirka -- li guang lig.f...@cn.fujitsu.com linux kernel team at FNST, china -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 1/2] helper of copy-storage-* features
nfusing; I might go with 'bool generate',
> where true means generate, and false means delete.
right, will fix.
>
> > +{
> > +char *tmp_dir = NULL, *outbuf = NULL;
> > +char *img_tool = driver->qemuImgBinary;
>
> Don't grab this field directly. Instead, use qemuFindQemuImgBinary(driver).
driver->qemuImgBinary is useful, I've initiated it.
why don't we use it?
>
> > +virCommandPtr cmd = NULL;
> > +int i, ret = -1;
> > +
> > +if (!def->ndisks)
> > +return 0;
> > +
> > +if (img_tool == NULL) {
> > +virReportError(VIR_ERR_INTERNAL_ERROR,
> > + "%s", _("unable to find kvm-img or qemu-img"));
> > +goto error;
> > +}
> > +
> > +for (i = 0; i < def->ndisks; i++) {
> > +if (STRNEQ(def->disks[i]->driverName, "qemu"))
> > +continue;
>
> You need to rebase your patches on top of the latest libvirt.git. The
> driverName field no longer exists; it is now an enum value named 'format'.
OK.
>
> > +if (def->disks[i]->src == NULL)
> > +continue;
> > +if (def->disks[i]->driverType == NULL)
> > +continue;
> > +if (virFileExists(def->disks[i]->src) && gen_del)
> > +continue;
> > +if (!gen_del && !virFileExists(def->disks[i]->src))
> > +continue;
> > +if ((tmp_dir = mdir_name(def->disks[i]->src)) == NULL)
> > +continue;
> > +if (!virFileExists(tmp_dir))
> > +if (virFileMakePath(tmp_dir) < 0)
> > +continue;
> > +if (gen_del) {
> > +cmd = virCommandNewArgList(img_tool, "create", "-f",
> > + def->disks[i]->driverType,
> > def->disks[i]->src, NULL);
> > +if (STREQ(def->disks[i]->driverType, "qcow2") ||
> > +STREQ(def->disks[i]->driverType, "qcow"))
> > +virCommandAddArgFormat(cmd, "%lluK", 0xff);
>
> Ouch. You should not be passing in random sizes to qemu - if you need
> to know the source size in order to create a file on the destination
> side, then we HAVE to modify the migration cookie in order to pass
> sizing information when the new flag is present.
>
passing by cookie seems a little rough,
these sizes are not random, they're
the max size of their format.
does setting max size hurt? the disk images are sparse files,
and after qemu migration finished, size will be right.
> > +} else {
> > +if (unlink(def->disks[i]->src) < 0) {
> > +virReportError(errno, "%s", _("fail to unlink disk image
> > file"));
> > +goto cleanup;
>
> Are you sure that this only ever unlink()s files that you just created,
> or does it have the possibility of unlinking a file that already existed
> prior to the migration attempt?
>
--
li guang lig.f...@cn.fujitsu.com
linux kernel team at FNST, china
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v13] support offline migration
在 2012-11-08四的 21:50 -0700，Eric Blake写道： > On 11/08/2012 09:31 PM, li guang wrote: > >>> seem flags was forgotten at qemuDomainMigratePrepare3, so any > >>> preparation for offline migration will be impossible, isn't it? > >>> do you mean I should change MigratePrepare functions to add > >>> flags as a parameter? > >> > >> Huh? qemuDomainMigratePrepare3 already has a flags argument (arg 8), > >> and it is directly related to the flags argument that was originally > >> passed to virDomainMigrate() in libvirt.c. > >> > > > > please check qemuMigrationPrepareDirect called in > > qemuDomainMigratePrepare3 > > qemuMigrationPrepareDirect is not a callback, and not a public API, so > you are free to change its signature and add a flags parameter if that > is necessary to get the information to the right places. The only > signatures you can't change are in src/libvirt.c and in functions > serving as callbacks registered through signatures in src/driver.h. > OK, will change. -- li guang lig.f...@cn.fujitsu.com linux kernel team at FNST, china -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v13] support offline migration
在 2012-11-08四的 21:06 -0700，Eric Blake写道： > On 11/08/2012 08:54 PM, li guang wrote: > > 在 2012-11-08四的 20:28 -0700，Eric Blake写道： > >> On 11/08/2012 07:57 PM, li guang wrote: > >>>> What if you want to offline migrate a domain that is currently running? > >>>> I think it's better to first move qemuDomainCheckEjectableMedia down to > >>>> qemuMigrationBegin in a separate patch and then just use the code from > >>>> v12 (without using the offline label). > >>> > >>> sorry, I don't like to do offline migrate for a domain that's running. > >> > >> Why not, when we've already argued it can be useful? You don't have to > >> support it in the same patch, but you should at least take the advice on > >> how to refactor things so that someone else that does like the idea can > >> extend things to provide it. There's nothing wrong with having > >> persistent definitions of the same domain on more than one machine, as > >> long as only one machine at a time is running it; and after all, with > >> live migration, if you _don't_ pass the --undefinesource flag, you will > >> be left in the same situation where a persistent domain on the source is > >> left behind even when the running domain has migrated. > > > > I mean we should do this explicitly, e.g. an flag to notify us we are > > doing job for active domain by walking through offline path. > > I said this before, at comment on virsh change. > > You ARE being explicit when you say 'virsh migrate --offline'. If the > domain is transient, it must fail, but if the domain is persistent, then > whether or not it is running, you are requesting that ONLY the offline > state be migrated. reasonable? maybe. > > >>> > >>> without this how do you know you a offline migration at target side? > >> > >> By the presence or absence of the flag. If the flag is present, you are > > > > seem flags was forgotten at qemuDomainMigratePrepare3, so any > > preparation for offline migration will be impossible, isn't it? > > do you mean I should change MigratePrepare functions to add > > flags as a parameter? > > Huh? qemuDomainMigratePrepare3 already has a flags argument (arg 8), > and it is directly related to the flags argument that was originally > passed to virDomainMigrate() in libvirt.c. > please check qemuMigrationPrepareDirect called in qemuDomainMigratePrepare3 -- li guang lig.f...@cn.fujitsu.com linux kernel team at FNST, china -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v13] support offline migration
在 2012-11-08四的 20:28 -0700，Eric Blake写道： > On 11/08/2012 07:57 PM, li guang wrote: > >> What if you want to offline migrate a domain that is currently running? > >> I think it's better to first move qemuDomainCheckEjectableMedia down to > >> qemuMigrationBegin in a separate patch and then just use the code from > >> v12 (without using the offline label). > > > > sorry, I don't like to do offline migrate for a domain that's running. > > Why not, when we've already argued it can be useful? You don't have to > support it in the same patch, but you should at least take the advice on > how to refactor things so that someone else that does like the idea can > extend things to provide it. There's nothing wrong with having > persistent definitions of the same domain on more than one machine, as > long as only one machine at a time is running it; and after all, with > live migration, if you _don't_ pass the --undefinesource flag, you will > be left in the same situation where a persistent domain on the source is > left behind even when the running domain has migrated. I mean we should do this explicitly, e.g. an flag to notify us we are doing job for active domain by walking through offline path. I said this before, at comment on virsh change. > > >> > >> Oh, I'm sorry for not noticing this earlier, but why exactly do we need > >> this element in migration cookie? It doesn't look like we need > >> to > >> store some additional data required for offline migration. I think just > >> passing the VIR_MIGRATE_OFFLINE flag will be better. Not to mention that > >> if an older > >> libvirt gets a cookie with element, it will just ignore it > >> while passing a flag (which the code should already been doing anyway) > >> should > >> make it fail for unsupported flag. > > > > without this how do you know you a offline migration at target side? > > By the presence or absence of the flag. If the flag is present, you are seem flags was forgotten at qemuDomainMigratePrepare3, so any preparation for offline migration will be impossible, isn't it? do you mean I should change MigratePrepare functions to add flags as a parameter? > doing an offline migration. I agree that we don't need to add anything > to the cookie, since the only way to get offline migration is via the > new flag, and both source and destination will see the same set of flags. > -- li guang lig.f...@cn.fujitsu.com linux kernel team at FNST, china -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 2/2] init qemu_driver's qemuImgBinary field
Hi, Eric
any comment on this patch?
在 2012-11-06二的 16:09 +0800，li guang写道：
> ping ...
>
> 在 2012-11-01四的 08:40 +0800，liguang写道：
> > Signed-off-by: liguang
> > ---
> > src/qemu/qemu_domain.c |2 +-
> > src/qemu/qemu_driver.c |3 +++
> > 2 files changed, 4 insertions(+), 1 deletions(-)
> >
> > diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> > index 17ae3b9..ac16772 100644
> > --- a/src/qemu/qemu_domain.c
> > +++ b/src/qemu/qemu_domain.c
> > @@ -1654,7 +1654,7 @@ qemuDomainSnapshotForEachQcow2Raw(struct qemud_driver
> > *driver,
> > int i;
> > bool skipped = false;
> >
> > -qemuimgarg[0] = qemuFindQemuImgBinary(driver);
> > +qemuimgarg[0] = driver->qemuImgBinary;
> > if (qemuimgarg[0] == NULL) {
> > /* qemuFindQemuImgBinary set the error */
> > return -1;
> > diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> > index 97ad23e..882e95a 100644
> > --- a/src/qemu/qemu_driver.c
> > +++ b/src/qemu/qemu_driver.c
> > @@ -624,6 +624,9 @@ qemudStartup(int privileged) {
> > if (!qemu_driver->domainEventState)
> > goto error;
> >
> > +/*find kvm-img or qemu-img*/
> > +qemuFindQemuImgBinary(qemu_driver);
> > +
> > /* read the host sysinfo */
> > if (privileged)
> > qemu_driver->hostsysinfo = virSysinfoRead();
>
--
li guang lig.f...@cn.fujitsu.com
linux kernel team at FNST, china
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v13] support offline migration
在 2012-11-09五的 08:44 +0800，li guang写道：
> > diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> > index 978af57..6c2bf98 100644
> > --- a/src/qemu/qemu_driver.c
> > +++ b/src/qemu/qemu_driver.c
> > @@ -9796,7 +9796,7 @@ qemuDomainMigrateBegin3(virDomainPtr domain,
> > asyncJob = QEMU_ASYNC_JOB_NONE;
> > }
> >
> > -if (!virDomainObjIsActive(vm)) {
> > +if (!virDomainObjIsActive(vm) && !(flags & VIR_MIGRATE_OFFLINE))
> {
> > virReportError(VIR_ERR_OPERATION_INVALID,
> > "%s", _("domain is not running"));
> > goto endjob;
> > @@ -9805,9 +9805,9 @@ qemuDomainMigrateBegin3(virDomainPtr domain,
> > /* Check if there is any ejected media.
> > * We don't want to require them on the destination.
> > */
> > -
> > -if (qemuDomainCheckEjectableMedia(driver, vm, asyncJob) < 0)
> > -goto endjob;
> > +if (virDomainObjIsActive(vm))
> > +if (qemuDomainCheckEjectableMedia(driver, vm, asyncJob) < 0)
> > +goto endjob;
> >
> > if (!(xml = qemuMigrationBegin(driver, vm, xmlin, dname,
> > cookieout, cookieoutlen,
>
> What if you want to offline migrate a domain that is currently running?
> I think it's better to first move qemuDomainCheckEjectableMedia down to
> qemuMigrationBegin in a separate patch and then just use the code from
> v12 (without using the offline label).
sorry, I don't like to do offline migrate for a domain that's running.
>
> > diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> > index 5f8a9c5..66fbc02 100644
> > --- a/src/qemu/qemu_migration.c
> > +++ b/src/qemu/qemu_migration.c
> > @@ -72,6 +72,7 @@ enum qemuMigrationCookieFlags {
> > QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE,
> > QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT,
> > QEMU_MIGRATION_COOKIE_FLAG_NETWORK,
> > +QEMU_MIGRATION_COOKIE_FLAG_OFFLINE,
> >
> > QEMU_MIGRATION_COOKIE_FLAG_LAST
> > };
> > @@ -79,13 +80,14 @@ enum qemuMigrationCookieFlags {
> > VIR_ENUM_DECL(qemuMigrationCookieFlag);
> > VIR_ENUM_IMPL(qemuMigrationCookieFlag,
> >QEMU_MIGRATION_COOKIE_FLAG_LAST,
> > - "graphics", "lockstate", "persistent", "network");
> > + "graphics", "lockstate", "persistent", "network",
> "offline");
> >
> > enum qemuMigrationCookieFeatures {
> > QEMU_MIGRATION_COOKIE_GRAPHICS = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_GRAPHICS),
> > QEMU_MIGRATION_COOKIE_LOCKSTATE = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE),
> > QEMU_MIGRATION_COOKIE_PERSISTENT = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT),
> > QEMU_MIGRATION_COOKIE_NETWORK = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_NETWORK),
> > +QEMU_MIGRATION_COOKIE_OFFLINE = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_OFFLINE),
> > };
> >
> > typedef struct _qemuMigrationCookieGraphics
> qemuMigrationCookieGraphics;
> > @@ -594,6 +596,9 @@ qemuMigrationCookieXMLFormat(struct qemud_driver
> *driver,
> > if ((mig->flags & QEMU_MIGRATION_COOKIE_NETWORK) && mig->network)
> > qemuMigrationCookieNetworkXMLFormat(buf, mig->network);
> >
> > +if (mig->flags & QEMU_MIGRATION_COOKIE_OFFLINE)
> > +virBufferAsprintf(buf, " \n");
> > +
> > virBufferAddLit(buf, "\n");
> > return 0;
> > }
> > @@ -874,6 +879,11 @@
> qemuMigrationCookieXMLParse(qemuMigrationCookiePtr mig,
> > (!(mig->network = qemuMigrationCookieNetworkXMLParse(ctxt
> > goto error;
> >
> > +if ((flags & QEMU_MIGRATION_COOKIE_OFFLINE)) {
> > +if (virXPathBoolean("count(./offline) > 0", ctxt))
> > +mig->flags |= QEMU_MIGRATION_COOKIE_OFFLINE;
> > +}
> > +
> > return 0;
> >
> > error:
> > @@ -938,6 +948,10 @@ qemuMigrationBakeCookie(qemuMigrationCookiePtr
> mig,
> > return -1;
> > }
> >
> > +if (flags & QEMU_MIGRATION_COOKIE_OFFLINE) {
> > +mig->flags |= QEMU_MIGRATION_COOKIE_OFFLINE;
> > +}
> > +
> > if (!(*cookieout = qemuMigrationCookieXMLFormatStr(driver, mig)))
> > return -1;
> >
>
> Oh, I'
Re: [libvirt] [PATCH v3 1/2] helper of copy-storage-* features
Hi, Eric
any comment on this patch?
在 2012-11-06二的 16:09 +0800，li guang写道：
> ping ...
> 在 2012-11-01四的 08:40 +0800，liguang写道：
> > help to create disk images copy-storage-* required,
> > try to do non-shared migration without bothering to
> > create disk images at target by hand.
> >
> > consider this situation:
> > 1. non-shared migration
> >virsh migrate --copy-storage-all ...
> > 2. migration fails
> > 3. create disk images required
> >qemu-img create ...
> > 4 migration run smoothly
> > so, try do remove step 2, 3, 4
> >
> > this kind of usage had been discussed before,
> > http://www.redhat.com/archives/libvir-list/2011-December/msg00451.html
> >
> > maybe there're some flaws:
> > - It did not handle more about complete situations
> > suggested by Daniel P. Berrange,
> > https://www.redhat.com/archives/libvir-list/2012-October/msg00407.html
> > but may try to take care of them later.
> > so, now only normal disk image files be handled.
> > - for creation of disk images, size was setting as 0x boldly,
> > hope it can consolidate qemu, haven't constructed a comfortable
> > idea to solve it.
> >
> > v2:
> > 1. handle disk encrytion case
> > 2. check kvm-img & qemu-img
> > 3. set disk image size to 0xfffK bytes blindly
> >
> > v3:
> > 1.use qemuImgBinary to create disk image
> > 2.set max size for different disk image format respectively
> > qcow and qcow2: 1PiB
> > qed:64TiB
> > raw:1TiB
> > from qemu's setting,
> > qcow and qcow2's max size is 2EiB,
> > qed's max size is 64TiB
> > raw's max size is 1TiB
> >
> > Signed-off-by: liguang
> > ---
> > src/qemu/qemu_migration.c | 122
> > -
> > 1 files changed, 120 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> > index db69a0a..80abb51 100644
> > --- a/src/qemu/qemu_migration.c
> > +++ b/src/qemu/qemu_migration.c
> > @@ -49,6 +49,7 @@
> > #include "storage_file.h"
> > #include "viruri.h"
> > #include "hooks.h"
> > +#include "dirname.h"
> >
> >
> > #define VIR_FROM_THIS VIR_FROM_QEMU
> > @@ -70,6 +71,7 @@ enum qemuMigrationCookieFlags {
> > QEMU_MIGRATION_COOKIE_FLAG_GRAPHICS,
> > QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE,
> > QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT,
> > +QEMU_MIGRATION_COOKIE_FLAG_COPYSTORAGE,
> >
> > QEMU_MIGRATION_COOKIE_FLAG_LAST
> > };
> > @@ -77,12 +79,13 @@ enum qemuMigrationCookieFlags {
> > VIR_ENUM_DECL(qemuMigrationCookieFlag);
> > VIR_ENUM_IMPL(qemuMigrationCookieFlag,
> >QEMU_MIGRATION_COOKIE_FLAG_LAST,
> > - "graphics", "lockstate", "persistent");
> > + "graphics", "lockstate", "persistent", "copystorage");
> >
> > enum qemuMigrationCookieFeatures {
> > QEMU_MIGRATION_COOKIE_GRAPHICS = (1 <<
> > QEMU_MIGRATION_COOKIE_FLAG_GRAPHICS),
> > QEMU_MIGRATION_COOKIE_LOCKSTATE = (1 <<
> > QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE),
> > QEMU_MIGRATION_COOKIE_PERSISTENT = (1 <<
> > QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT),
> > +QEMU_MIGRATION_COOKIE_COPYSTORAGE = (1 <<
> > QEMU_MIGRATION_COOKIE_FLAG_COPYSTORAGE),
> > };
> >
> > typedef struct _qemuMigrationCookieGraphics qemuMigrationCookieGraphics;
> > @@ -439,6 +442,9 @@ qemuMigrationCookieXMLFormat(struct qemud_driver
> > *driver,
> > virBufferAdjustIndent(buf, -2);
> > }
> >
> > +if (mig->flags & QEMU_MIGRATION_COOKIE_COPYSTORAGE)
> > +virBufferAsprintf(buf, " \n");
> > +
> > virBufferAddLit(buf, "\n");
> > return 0;
> > }
> > @@ -662,6 +668,11 @@ qemuMigrationCookieXMLParse(qemuMigrationCookiePtr mig,
> > VIR_FREE(nodes);
> > }
> >
> > +if ((flags & QEMU_MIGRATION_COOKIE_COPYSTORAGE)) {
> > +if (virXPathBoolean("count(./copystorage) > 0", ctxt))
> > +mig->flags |= QEMU_MIGRATION_COOKIE_COPYSTORAGE;
> > +}
> > +
> > return 0;
> >
> > error:
> > @@ -721,6 +732,9 @@ qemuMigrationBakeCookie(qemuMigrationCookiePtr mig,
> > qemuMigration
Re: [libvirt] [PATCH v13] support offline migration
在 2012-11-06二的 09:00 -0700，Eric Blake写道： > On 11/06/2012 04:16 AM, Jiri Denemark wrote: > > > > Another thing I didn't notice last time :-( Is there any reason why offline > > migrating a running domain should be forbidden? But even if there was a > > reason, this check doesn't belong to virsh. > > Good observation. I think that supporting --offline migration for a > running domain DOES make sense - migrate the persistent state only, so > that on the destination, the domain is now defined but not running, and > the running state continues on the source. There's no problem with > having a persistent definition on more than one machine (unlike with > running migration, where we must ensure that the domain is on only one > host at a time with smooth handoff between hosts). > IMHO: I don't like to act as a smuggler for active domain, offline is offline, online is online, you should not do any real job for online when you're doing job for offline, of course, it's pretty semantic, so, I reject this case at virsh instead of migration process. If you need sugar from offline action, I think at least an explicit flag is required to let offline do it for you. -- liguanglig.f...@cn.fujitsu.com FNST linux kernel team -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v13] support offline migration
Hi, Jiri, Daniel
Any comment on this patch?
在 2012-11-05一的 12:17 +0800，liguang写道：
> original migration did not aware of offline case,
> so, try to support offline migration quietly
> (did not disturb original migration) by pass
> VIR_MIGRATE_OFFLINE flag to migration APIs if only
> the domain is really inactive, and
> migration process will not puzzled by domain
> offline and exit unexpectedly.
> these changes did not take care of disk images the
> domain required, for them could be transferred by
> other APIs as suggested, then VIR_MIGRATE_OFFLINE
> must not combined with VIR_MIGRATE_NON_SHARED_*.
> if you want a persistent migration,
> you should do "virsh migrate --persistent" youself.
>
> v12:
> rebased for conflicting with commit 2f3e2c0c434218a3d656c08779cb98b327170e11,
> and take in some messages from Doug Goldstein's patch
> https://www.redhat.com/archives/libvir-list/2012-October/msg00957.html
>
> v13:
> changed for comments from Jiri Denemark
> https://www.redhat.com/archives/libvir-list/2012-November/msg00153.html
>
> Signed-off-by: liguang
> ---
> include/libvirt/libvirt.h.in |1 +
> src/qemu/qemu_driver.c |8 ++--
> src/qemu/qemu_migration.c| 99
> +-
> src/qemu/qemu_migration.h|3 +-
> tools/virsh-domain.c | 10
> 5 files changed, 95 insertions(+), 26 deletions(-)
>
> diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
> index fe58c08..1e0500d 100644
> --- a/include/libvirt/libvirt.h.in
> +++ b/include/libvirt/libvirt.h.in
> @@ -1090,6 +1090,7 @@ typedef enum {
> * whole migration process;
> this will be used automatically
> * when supported */
> VIR_MIGRATE_UNSAFE= (1 << 9), /* force migration even if it
> is considered unsafe */
> +VIR_MIGRATE_OFFLINE = (1 << 10), /* offline migrate */
> } virDomainMigrateFlags;
>
> /* Domain migration. */
> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> index 978af57..6c2bf98 100644
> --- a/src/qemu/qemu_driver.c
> +++ b/src/qemu/qemu_driver.c
> @@ -9796,7 +9796,7 @@ qemuDomainMigrateBegin3(virDomainPtr domain,
> asyncJob = QEMU_ASYNC_JOB_NONE;
> }
>
> -if (!virDomainObjIsActive(vm)) {
> +if (!virDomainObjIsActive(vm) && !(flags & VIR_MIGRATE_OFFLINE)) {
> virReportError(VIR_ERR_OPERATION_INVALID,
> "%s", _("domain is not running"));
> goto endjob;
> @@ -9805,9 +9805,9 @@ qemuDomainMigrateBegin3(virDomainPtr domain,
> /* Check if there is any ejected media.
> * We don't want to require them on the destination.
> */
> -
> -if (qemuDomainCheckEjectableMedia(driver, vm, asyncJob) < 0)
> -goto endjob;
> +if (virDomainObjIsActive(vm))
> +if (qemuDomainCheckEjectableMedia(driver, vm, asyncJob) < 0)
> +goto endjob;
>
> if (!(xml = qemuMigrationBegin(driver, vm, xmlin, dname,
> cookieout, cookieoutlen,
> diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> index 5f8a9c5..66fbc02 100644
> --- a/src/qemu/qemu_migration.c
> +++ b/src/qemu/qemu_migration.c
> @@ -72,6 +72,7 @@ enum qemuMigrationCookieFlags {
> QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE,
> QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT,
> QEMU_MIGRATION_COOKIE_FLAG_NETWORK,
> +QEMU_MIGRATION_COOKIE_FLAG_OFFLINE,
>
> QEMU_MIGRATION_COOKIE_FLAG_LAST
> };
> @@ -79,13 +80,14 @@ enum qemuMigrationCookieFlags {
> VIR_ENUM_DECL(qemuMigrationCookieFlag);
> VIR_ENUM_IMPL(qemuMigrationCookieFlag,
>QEMU_MIGRATION_COOKIE_FLAG_LAST,
> - "graphics", "lockstate", "persistent", "network");
> + "graphics", "lockstate", "persistent", "network", "offline");
>
> enum qemuMigrationCookieFeatures {
> QEMU_MIGRATION_COOKIE_GRAPHICS = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_GRAPHICS),
> QEMU_MIGRATION_COOKIE_LOCKSTATE = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE),
> QEMU_MIGRATION_COOKIE_PERSISTENT = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT),
> QEMU_MIGRATION_COOKIE_NETWORK = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_NETWORK),
> +QEMU_MIGRATION_COOKIE_OFFLINE = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_OFFLINE),
> };
>
> typedef struct _qemuMigrationCookieGraphics qemuMigrationCookieGraphics;
> @@ -594,6 +596,9 @@ qemuMigrationCookieXMLFormat(struct qemud_driver *driver,
> if ((mig->flags & QEMU_MIGRATION_COOKIE_NETWORK) && mig->network)
> qemuMigrationCookieNetworkXMLFormat(buf, mig->network);
>
> +if (mig->flags & QEMU_MIGRATION_COOKIE_OFFLINE)
> +virBufferAsprintf(buf, " \n");
> +
> virBufferAddLit(buf, "\n");
> return 0;
> }
> @@ -874,6 +879,11 @@ qemuMigrationCookieXMLParse(qemuMigrationCookiePtr mig,
> (!(mig->network = qemuMigrationCookieNetworkXMLParse(ctxt))
Re: [libvirt] [PATCH v3 2/2] init qemu_driver's qemuImgBinary field
ping ...
在 2012-11-01四的 08:40 +0800，liguang写道：
> Signed-off-by: liguang
> ---
> src/qemu/qemu_domain.c |2 +-
> src/qemu/qemu_driver.c |3 +++
> 2 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> index 17ae3b9..ac16772 100644
> --- a/src/qemu/qemu_domain.c
> +++ b/src/qemu/qemu_domain.c
> @@ -1654,7 +1654,7 @@ qemuDomainSnapshotForEachQcow2Raw(struct qemud_driver
> *driver,
> int i;
> bool skipped = false;
>
> -qemuimgarg[0] = qemuFindQemuImgBinary(driver);
> +qemuimgarg[0] = driver->qemuImgBinary;
> if (qemuimgarg[0] == NULL) {
> /* qemuFindQemuImgBinary set the error */
> return -1;
> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> index 97ad23e..882e95a 100644
> --- a/src/qemu/qemu_driver.c
> +++ b/src/qemu/qemu_driver.c
> @@ -624,6 +624,9 @@ qemudStartup(int privileged) {
> if (!qemu_driver->domainEventState)
> goto error;
>
> +/*find kvm-img or qemu-img*/
> +qemuFindQemuImgBinary(qemu_driver);
> +
> /* read the host sysinfo */
> if (privileged)
> qemu_driver->hostsysinfo = virSysinfoRead();
--
liguanglig.f...@cn.fujitsu.com
FNST linux kernel team
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3 1/2] helper of copy-storage-* features
ping ...
在 2012-11-01四的 08:40 +0800，liguang写道：
> help to create disk images copy-storage-* required,
> try to do non-shared migration without bothering to
> create disk images at target by hand.
>
> consider this situation:
> 1. non-shared migration
>virsh migrate --copy-storage-all ...
> 2. migration fails
> 3. create disk images required
>qemu-img create ...
> 4 migration run smoothly
> so, try do remove step 2, 3, 4
>
> this kind of usage had been discussed before,
> http://www.redhat.com/archives/libvir-list/2011-December/msg00451.html
>
> maybe there're some flaws:
> - It did not handle more about complete situations
> suggested by Daniel P. Berrange,
> https://www.redhat.com/archives/libvir-list/2012-October/msg00407.html
> but may try to take care of them later.
> so, now only normal disk image files be handled.
> - for creation of disk images, size was setting as 0x boldly,
> hope it can consolidate qemu, haven't constructed a comfortable
> idea to solve it.
>
> v2:
> 1. handle disk encrytion case
> 2. check kvm-img & qemu-img
> 3. set disk image size to 0xfffK bytes blindly
>
> v3:
> 1.use qemuImgBinary to create disk image
> 2.set max size for different disk image format respectively
> qcow and qcow2: 1PiB
> qed:64TiB
> raw:1TiB
> from qemu's setting,
> qcow and qcow2's max size is 2EiB,
> qed's max size is 64TiB
> raw's max size is 1TiB
>
> Signed-off-by: liguang
> ---
> src/qemu/qemu_migration.c | 122
> -
> 1 files changed, 120 insertions(+), 2 deletions(-)
>
> diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> index db69a0a..80abb51 100644
> --- a/src/qemu/qemu_migration.c
> +++ b/src/qemu/qemu_migration.c
> @@ -49,6 +49,7 @@
> #include "storage_file.h"
> #include "viruri.h"
> #include "hooks.h"
> +#include "dirname.h"
>
>
> #define VIR_FROM_THIS VIR_FROM_QEMU
> @@ -70,6 +71,7 @@ enum qemuMigrationCookieFlags {
> QEMU_MIGRATION_COOKIE_FLAG_GRAPHICS,
> QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE,
> QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT,
> +QEMU_MIGRATION_COOKIE_FLAG_COPYSTORAGE,
>
> QEMU_MIGRATION_COOKIE_FLAG_LAST
> };
> @@ -77,12 +79,13 @@ enum qemuMigrationCookieFlags {
> VIR_ENUM_DECL(qemuMigrationCookieFlag);
> VIR_ENUM_IMPL(qemuMigrationCookieFlag,
>QEMU_MIGRATION_COOKIE_FLAG_LAST,
> - "graphics", "lockstate", "persistent");
> + "graphics", "lockstate", "persistent", "copystorage");
>
> enum qemuMigrationCookieFeatures {
> QEMU_MIGRATION_COOKIE_GRAPHICS = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_GRAPHICS),
> QEMU_MIGRATION_COOKIE_LOCKSTATE = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE),
> QEMU_MIGRATION_COOKIE_PERSISTENT = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT),
> +QEMU_MIGRATION_COOKIE_COPYSTORAGE = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_COPYSTORAGE),
> };
>
> typedef struct _qemuMigrationCookieGraphics qemuMigrationCookieGraphics;
> @@ -439,6 +442,9 @@ qemuMigrationCookieXMLFormat(struct qemud_driver *driver,
> virBufferAdjustIndent(buf, -2);
> }
>
> +if (mig->flags & QEMU_MIGRATION_COOKIE_COPYSTORAGE)
> +virBufferAsprintf(buf, " \n");
> +
> virBufferAddLit(buf, "\n");
> return 0;
> }
> @@ -662,6 +668,11 @@ qemuMigrationCookieXMLParse(qemuMigrationCookiePtr mig,
> VIR_FREE(nodes);
> }
>
> +if ((flags & QEMU_MIGRATION_COOKIE_COPYSTORAGE)) {
> +if (virXPathBoolean("count(./copystorage) > 0", ctxt))
> +mig->flags |= QEMU_MIGRATION_COOKIE_COPYSTORAGE;
> +}
> +
> return 0;
>
> error:
> @@ -721,6 +732,9 @@ qemuMigrationBakeCookie(qemuMigrationCookiePtr mig,
> qemuMigrationCookieAddPersistent(mig, dom) < 0)
> return -1;
>
> +if (flags & QEMU_MIGRATION_COOKIE_COPYSTORAGE)
> +mig->flags |= QEMU_MIGRATION_COOKIE_COPYSTORAGE;
> +
> if (!(*cookieout = qemuMigrationCookieXMLFormatStr(driver, mig)))
> return -1;
>
> @@ -1168,6 +1182,14 @@ char *qemuMigrationBegin(struct qemud_driver *driver,
> QEMU_MIGRATION_COOKIE_LOCKSTATE) < 0)
> goto cleanup;
>
> +if (flags & (VIR_MIGRATE_NON_SHARED_DISK |
> + VIR_MIGRATE_NON_SHARED_INC)) {
> +if (qemuMigrationBakeCookie(mig, driver, vm,
> +cookieout, cookieoutlen,
> +QEMU_MIGRATION_COOKIE_COPYSTORAGE) < 0)
> +goto cleanup;
> +}
> +
> if (xmlin) {
> if (!(def = virDomainDefParseString(driver->caps, xmlin,
> QEMU_EXPECTED_VIRT_TYPES,
> @@ -1215,6 +1237,89 @@ qemuMigrationPrepareCleanup(struct qemud_driver
> *driver,
> qemuDomainObjDiscardAsyncJob(driver, vm);
> }
>
> +/*
> + if gen_del is 1, find out disk images migration required,
> + so try to generate them at target,
Re: [libvirt] [PATCH][reordered] gitignore: ignore more files
在 2012-11-02五的 12:05 +0100，Peter Krempa写道： > On 11/01/12 10:30, liguang wrote: > > ignore *.patch, cscope.po.out, cscope.in.out > > > > Signed-off-by: liguang > > --- > > .gitignore |3 +++ > > 1 files changed, 3 insertions(+), 0 deletions(-) > > > > diff --git a/.gitignore b/.gitignore > > index 1cd2d45..3672131 100644 > > --- a/.gitignore > > +++ b/.gitignore > > @@ -13,6 +13,7 @@ > > *.loT > > *.o > > *.orig > > +*.patch > > Hm, also I'd prefer having .patch kept unignored for two reasons: > 1) there are several .patch files in the tree: > > $ git ls-files | grep "\.patch" > docs/api_extension/0001-add-to-xml.patch > docs/api_extension/0002-add-new-public-API.patch > docs/api_extension/0003-define-internal-driver-API.patch > docs/api_extension/0004-implement-the-public-APIs.patch > docs/api_extension/0005-implement-the-remote-protocol.patch > docs/api_extension/0006-make-old-API-trivially-wrap-to-new-API.patch > docs/api_extension/0007-add-virsh-support.patch > docs/api_extension/0008-support-new-xml.patch > docs/api_extension/0009-support-all-flags-in-test-driver.patch > docs/api_extension/0010-improve-vcpu-support-in-qemu-command-line.patch > docs/api_extension/0011-complete-vcpu-support-in-qemu-driver.patch > docs/api_extension/0012-improve-vcpu-support-in-xen-command-line.patch > docs/api_extension/0013-improve-getting-xen-vcpu-counts.patch > docs/api_extension/0014-improve-setting-xen-vcpu-counts.patch > docs/api_extension/0015-remove-dead-xen-code.patch > > so changes to these would pose problems > > 2) this actually reminds you clean your tree before pushing changes and > removes the possibility of accidentally sending wrong patches with > "git send-email *.patch" > Maybe, I'll remove *.patch ignore > > > *.pyc > > *.rej > > *.s > > Peter > -- liguanglig.f...@cn.fujitsu.com FNST linux kernel team -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v12] support offline migration
在 2012-11-02五的 12:10 +，Daniel P. Berrange写道： > On Fri, Nov 02, 2012 at 09:30:27AM +0800, liguang wrote: > > original migration did not aware of offline case, > > so, try to support offline migration quietly > > (did not disturb original migration) by pass > > VIR_MIGRATE_OFFLINE flag to migration APIs if only > > the domain is really inactive, and > > migration process will not puzzled by domain > > offline and exit unexpectedly. > > these changes did not take care of disk images the > > domain required, for them could be transferred by > > other APIs as suggested, then VIR_MIGRATE_OFFLINE > > should not combined with VIR_MIGRATE_NON_SHARED_*. > > if you want a persistent migration, > > you should do "virsh migrate --persistent" youself. > > > > v12: > > rebased for conflicting with commit > > 2f3e2c0c434218a3d656c08779cb98b327170e11, > > and take in some messages from Doug Goldstein's patch > > https://www.redhat.com/archives/libvir-list/2012-October/msg00957.html > > Great, the patch is now behaving exactly as I expect. I've only > one question - in the logs of libvirtd on the target host I always > see a warning message: > > 2012-11-02 12:07:08.789+: 31375: warning : qemuDomainObjSetJobPhase:690 > : 'migration in' async job is owned by thread 31374 > > I'm not sure what we're doing to trigger it, but I think we need > to find out & avoid it. > OK, found it, will fix. > I would ack the patch if we can fix the warning > > Daniel -- liguanglig.f...@cn.fujitsu.com FNST linux kernel team -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v12] support offline migration
在 2012-11-02五的 15:32 +0100，Jiri Denemark写道：
> On Fri, Nov 02, 2012 at 09:30:27 +0800, liguang wrote:
> > original migration did not aware of offline case,
> > so, try to support offline migration quietly
> > (did not disturb original migration) by pass
> > VIR_MIGRATE_OFFLINE flag to migration APIs if only
> > the domain is really inactive, and
> > migration process will not puzzled by domain
> > offline and exit unexpectedly.
> > these changes did not take care of disk images the
> > domain required, for them could be transferred by
> > other APIs as suggested, then VIR_MIGRATE_OFFLINE
> > should not combined with VIR_MIGRATE_NON_SHARED_*.
> > if you want a persistent migration,
> > you should do "virsh migrate --persistent" youself.
> >
> > v12:
> > rebased for conflicting with commit
> > 2f3e2c0c434218a3d656c08779cb98b327170e11,
> > and take in some messages from Doug Goldstein's patch
> > https://www.redhat.com/archives/libvir-list/2012-October/msg00957.html
> >
> > Signed-off-by: liguang
> > ---
> > include/libvirt/libvirt.h.in |1 +
> > src/qemu/qemu_driver.c | 15 +
> > src/qemu/qemu_migration.c| 66
> > -
> > src/qemu/qemu_migration.h|3 +-
> > tools/virsh-domain.c | 10 ++
> > 5 files changed, 86 insertions(+), 9 deletions(-)
> >
> > diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
> > index 2b17cef..a8f641f 100644
> > --- a/include/libvirt/libvirt.h.in
> > +++ b/include/libvirt/libvirt.h.in
> > @@ -1089,6 +1089,7 @@ typedef enum {
> > * whole migration process;
> > this will be used automatically
> > * when supported */
> > VIR_MIGRATE_UNSAFE= (1 << 9), /* force migration even if
> > it is considered unsafe */
> > +VIR_MIGRATE_OFFLINE = (1 << 10), /* offline migrate */
> > } virDomainMigrateFlags;
> >
> > /* Domain migration. */
> > diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> > index 267bbf1..f5c05e4 100644
> > --- a/src/qemu/qemu_driver.c
> > +++ b/src/qemu/qemu_driver.c
> > @@ -9759,6 +9759,20 @@ qemuDomainMigrateBegin3(virDomainPtr domain,
> > }
> >
> > if (!virDomainObjIsActive(vm)) {
> > +if (flags & VIR_MIGRATE_OFFLINE) {
> > +if (flags & (VIR_MIGRATE_NON_SHARED_DISK|
> > + VIR_MIGRATE_NON_SHARED_INC)) {
> > +virReportError(VIR_ERR_OPERATION_INVALID,
> > + "%s", _("offline migration cannot handle
> > non-shared storage"));
> > +goto endjob;
> > +}
> > +if (!(flags & VIR_MIGRATE_PERSIST_DEST)) {
> > +virReportError(VIR_ERR_OPERATION_INVALID,
> > + "%s", _("offline migration must be
> > specified with the persistent flag set"));
> > +goto endjob;
> > +}
> > +goto offline;
> > +}
> > virReportError(VIR_ERR_OPERATION_INVALID,
> > "%s", _("domain is not running"));
> > goto endjob;
> > @@ -9771,6 +9785,7 @@ qemuDomainMigrateBegin3(virDomainPtr domain,
> > if (qemuDomainCheckEjectableMedia(driver, vm, asyncJob) < 0)
> > goto endjob;
> >
> > +offline:
> > if (!(xml = qemuMigrationBegin(driver, vm, xmlin, dname,
> > cookieout, cookieoutlen,
> > flags)))
>
> I think this label is pretty confusing since the code after it is not just for
> offline migration. Not to mention that this label is used to just skip calling
> qemuDomainCheckEjectableMedia(). I think it would look better as
>
> bool offline = !!(flags & VIR_MIGRATE_OFFLINE);
> ...
> if (!virDomainObjIsActive(vm)) {
> if (offline) {
> if (flags & (VIR_MIGRATE_NON_SHARED_DISK|
> VIR_MIGRATE_NON_SHARED_INC)) {
> virReportError(VIR_ERR_OPERATION_INVALID,
>"%s", _("offline migration cannot handle
> non-shared storage"));
> goto endjob;
> }
> if (!(flags & VIR_MIGRATE_PERSIST_DEST)) {
> virReportError(VIR_ERR_OPERATION_INVALID,
>"%s", _("offline migration must be specified
> with the persistent flag set"));
> goto endjob;
> }
> } else {
> virReportError(VIR_ERR_OPERATION_INVALID,
>"%s", _("domain is not running"));
> goto endjob;
> }
> }
>
> /* Check if there is any ejected media.
> * We don't want to require them on the destination.
> */
>
> if (!offline &&
> qemuDomainCheckEjectableMedia(driver, vm, asyncJob) < 0)
> goto endjob;
>
> if (!(xml = qemuMigrationBegin(driver, vm, xmlin,
Re: [libvirt] [PATCH v12] support offline migration
在 2012-11-02五的 11:42 -0500，Doug Goldstein写道： > On Thu, Nov 1, 2012 at 8:30 PM, liguang wrote: > > original migration did not aware of offline case, > > so, try to support offline migration quietly > > (did not disturb original migration) by pass > > VIR_MIGRATE_OFFLINE flag to migration APIs if only > > the domain is really inactive, and > > migration process will not puzzled by domain > > offline and exit unexpectedly. > > these changes did not take care of disk images the > > domain required, for them could be transferred by > > other APIs as suggested, then VIR_MIGRATE_OFFLINE > > should not combined with VIR_MIGRATE_NON_SHARED_*. > > if you want a persistent migration, > > you should do "virsh migrate --persistent" youself. > > > > v12: > > rebased for conflicting with commit > > 2f3e2c0c434218a3d656c08779cb98b327170e11, > > and take in some messages from Doug Goldstein's patch > > https://www.redhat.com/archives/libvir-list/2012-October/msg00957.html > > > > Signed-off-by: liguang > > --- > > Unfortunately the patch only pulled in my wording on the error > messages and not any of my other changes. Jiri's review saw all the > same issues I saw and corrected in my patch. The only reason I > submitted a patch is that I've had these same review comments in the > previous 9 iterations and they weren't getting addressed. > > You've sent e-mails complaining that its taking a long time to get > your patch merged into master yet you're not addressing code review > comments and then when someone does the work you aren't pulling it in. > I'm not giving you these comments as something to cherry pick what you > agree with and disagree with. > > Please address all the review comments (Daniel, Jiri and myself) > before you submit your next revision. OK, I'm trying to address them. > > -- > Doug -- liguanglig.f...@cn.fujitsu.com FNST linux kernel team -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v11] support offline migration
re-based.
2 weeks elapsed since my last patch,
it's no curious that conflict comes up,
so can you check this patch as soon as
possible this time?
在 2012-11-01四的 11:59 +，Daniel P. Berrange写道：
> Unfortunately this patch conflicts horribly with this recently
> merged patch
>
> commit 2f3e2c0c434218a3d656c08779cb98b327170e11
> Author: Kyle Mestery
> Date: Mon Oct 1 11:18:22 2012 -0400
>
> qemu_migration: Transport OVS per-port data during live migration
>
> so has many failures when applying. Can you rebase it, and include
> the additional fixes from Doug's patch here:
>
> https://www.redhat.com/archives/libvir-list/2012-October/msg00957.html
>
>
> Regards,
> Daniel
>
> On Thu, Nov 01, 2012 at 01:47:00PM +0800, li guang wrote:
> > ping ...
> >
> > 在 2012-10-23二的 16:09 +0800，li guang写道：
> > > ping ...
> > >
> > > 在 2012-10-18四的 08:42 +0800，liguang写道：
> > > > original migration did not aware of offline case,
> > > > so, try to support offline migration quietly
> > > > (did not disturb original migration) by pass
> > > > VIR_MIGRATE_OFFLINE flag to migration APIs if only
> > > > the domain is really inactive, and
> > > > migration process will not puzzled by domain
> > > > offline and exit unexpectedly.
> > > > these changes did not take care of disk images the
> > > > domain required, for them could be transferred by
> > > > other APIs as suggested, then VIR_MIGRATE_OFFLINE
> > > > should not combined with VIR_MIGRATE_NON_SHARED_*.
> > > > if you want a persistent migration,
> > > > you should do "virsh migrate --persistent" youself.
> > > >
> > > > Signed-off-by: liguang
> > > > ---
> > > > include/libvirt/libvirt.h.in |1 +
> > > > src/qemu/qemu_driver.c | 15 ++
> > > > src/qemu/qemu_migration.c| 60
> > > > +++--
> > > > src/qemu/qemu_migration.h|3 +-
> > > > tools/virsh-domain.c |6
> > > > 5 files changed, 75 insertions(+), 10 deletions(-)
> > > >
> > > > diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
> > > > index 81f12a4..1cebc21 100644
> > > > --- a/include/libvirt/libvirt.h.in
> > > > +++ b/include/libvirt/libvirt.h.in
> > > > @@ -995,6 +995,7 @@ typedef enum {
> > > > * whole migration
> > > > process; this will be used automatically
> > > > * when supported */
> > > > VIR_MIGRATE_UNSAFE= (1 << 9), /* force migration even
> > > > if it is considered unsafe */
> > > > +VIR_MIGRATE_OFFLINE = (1 << 10), /* offline migrate */
> > > > } virDomainMigrateFlags;
> > > >
> > > > /* Domain migration. */
> > > > diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> > > > index 97ad23e..38bfcab 100644
> > > > --- a/src/qemu/qemu_driver.c
> > > > +++ b/src/qemu/qemu_driver.c
> > > > @@ -9622,6 +9622,20 @@ qemuDomainMigrateBegin3(virDomainPtr domain,
> > > > }
> > > >
> > > > if (!virDomainObjIsActive(vm)) {
> > > > +if (flags & VIR_MIGRATE_OFFLINE) {
> > > > +if (flags & (VIR_MIGRATE_NON_SHARED_DISK|
> > > > + VIR_MIGRATE_NON_SHARED_INC)) {
> > > > +virReportError(VIR_ERR_OPERATION_INVALID,
> > > > + "%s", _("migrating storage handled by
> > > > volume APIs"));
> > > > +goto endjob;
> > > > +}
> > > > +if (!(flags & VIR_MIGRATE_PERSIST_DEST)) {
> > > > +virReportError(VIR_ERR_OPERATION_INVALID,
> > > > + "%s", _("VIR_MIGRATE_OFFLINE should
> > > > combined with VIR_MIGRATE_PERSIST_DEST"));
> > > > +goto endjob;
> > > > +}
> > > > +goto offline;
> > > > +}
> > > > virReportError(VIR_ERR_OPERATION_INVALID,
> > > > "%s", _("domain is not running"));
> > > > goto endjob;
> > >
Re: [libvirt] [PATCH v11] support offline migration
ping ...
在 2012-10-23二的 16:09 +0800，li guang写道：
> ping ...
>
> 在 2012-10-18四的 08:42 +0800，liguang写道：
> > original migration did not aware of offline case,
> > so, try to support offline migration quietly
> > (did not disturb original migration) by pass
> > VIR_MIGRATE_OFFLINE flag to migration APIs if only
> > the domain is really inactive, and
> > migration process will not puzzled by domain
> > offline and exit unexpectedly.
> > these changes did not take care of disk images the
> > domain required, for them could be transferred by
> > other APIs as suggested, then VIR_MIGRATE_OFFLINE
> > should not combined with VIR_MIGRATE_NON_SHARED_*.
> > if you want a persistent migration,
> > you should do "virsh migrate --persistent" youself.
> >
> > Signed-off-by: liguang
> > ---
> > include/libvirt/libvirt.h.in |1 +
> > src/qemu/qemu_driver.c | 15 ++
> > src/qemu/qemu_migration.c| 60
> > +++--
> > src/qemu/qemu_migration.h|3 +-
> > tools/virsh-domain.c |6
> > 5 files changed, 75 insertions(+), 10 deletions(-)
> >
> > diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
> > index 81f12a4..1cebc21 100644
> > --- a/include/libvirt/libvirt.h.in
> > +++ b/include/libvirt/libvirt.h.in
> > @@ -995,6 +995,7 @@ typedef enum {
> > * whole migration process;
> > this will be used automatically
> > * when supported */
> > VIR_MIGRATE_UNSAFE= (1 << 9), /* force migration even if
> > it is considered unsafe */
> > +VIR_MIGRATE_OFFLINE = (1 << 10), /* offline migrate */
> > } virDomainMigrateFlags;
> >
> > /* Domain migration. */
> > diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> > index 97ad23e..38bfcab 100644
> > --- a/src/qemu/qemu_driver.c
> > +++ b/src/qemu/qemu_driver.c
> > @@ -9622,6 +9622,20 @@ qemuDomainMigrateBegin3(virDomainPtr domain,
> > }
> >
> > if (!virDomainObjIsActive(vm)) {
> > +if (flags & VIR_MIGRATE_OFFLINE) {
> > +if (flags & (VIR_MIGRATE_NON_SHARED_DISK|
> > + VIR_MIGRATE_NON_SHARED_INC)) {
> > +virReportError(VIR_ERR_OPERATION_INVALID,
> > + "%s", _("migrating storage handled by
> > volume APIs"));
> > +goto endjob;
> > +}
> > +if (!(flags & VIR_MIGRATE_PERSIST_DEST)) {
> > +virReportError(VIR_ERR_OPERATION_INVALID,
> > + "%s", _("VIR_MIGRATE_OFFLINE should
> > combined with VIR_MIGRATE_PERSIST_DEST"));
> > +goto endjob;
> > +}
> > +goto offline;
> > +}
> > virReportError(VIR_ERR_OPERATION_INVALID,
> > "%s", _("domain is not running"));
> > goto endjob;
> > @@ -9634,6 +9648,7 @@ qemuDomainMigrateBegin3(virDomainPtr domain,
> > if (qemuDomainCheckEjectableMedia(driver, vm, asyncJob) < 0)
> > goto endjob;
> >
> > +offline:
> > if (!(xml = qemuMigrationBegin(driver, vm, xmlin, dname,
> > cookieout, cookieoutlen,
> > flags)))
> > diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> > index db69a0a..b2f921e 100644
> > --- a/src/qemu/qemu_migration.c
> > +++ b/src/qemu/qemu_migration.c
> > @@ -70,6 +70,7 @@ enum qemuMigrationCookieFlags {
> > QEMU_MIGRATION_COOKIE_FLAG_GRAPHICS,
> > QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE,
> > QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT,
> > +QEMU_MIGRATION_COOKIE_FLAG_OFFLINE,
> >
> > QEMU_MIGRATION_COOKIE_FLAG_LAST
> > };
> > @@ -77,12 +78,13 @@ enum qemuMigrationCookieFlags {
> > VIR_ENUM_DECL(qemuMigrationCookieFlag);
> > VIR_ENUM_IMPL(qemuMigrationCookieFlag,
> >QEMU_MIGRATION_COOKIE_FLAG_LAST,
> > - "graphics", "lockstate", "persistent");
> > + "graphics", "lockstate", "persistent", "offline");
> >
> > enum qemuMigrationCookieFeatures {
> > QEMU_MIGRATION_COOKIE_GRAPHICS = (1 <<
> > QEMU_MIGRATION_COOKIE_FLAG_
Re: [libvirt] [PATCH v11] support offline migration
ping ...
在 2012-10-18四的 08:42 +0800，liguang写道：
> original migration did not aware of offline case,
> so, try to support offline migration quietly
> (did not disturb original migration) by pass
> VIR_MIGRATE_OFFLINE flag to migration APIs if only
> the domain is really inactive, and
> migration process will not puzzled by domain
> offline and exit unexpectedly.
> these changes did not take care of disk images the
> domain required, for them could be transferred by
> other APIs as suggested, then VIR_MIGRATE_OFFLINE
> should not combined with VIR_MIGRATE_NON_SHARED_*.
> if you want a persistent migration,
> you should do "virsh migrate --persistent" youself.
>
> Signed-off-by: liguang
> ---
> include/libvirt/libvirt.h.in |1 +
> src/qemu/qemu_driver.c | 15 ++
> src/qemu/qemu_migration.c| 60 +++--
> src/qemu/qemu_migration.h|3 +-
> tools/virsh-domain.c |6
> 5 files changed, 75 insertions(+), 10 deletions(-)
>
> diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
> index 81f12a4..1cebc21 100644
> --- a/include/libvirt/libvirt.h.in
> +++ b/include/libvirt/libvirt.h.in
> @@ -995,6 +995,7 @@ typedef enum {
> * whole migration process;
> this will be used automatically
> * when supported */
> VIR_MIGRATE_UNSAFE= (1 << 9), /* force migration even if it
> is considered unsafe */
> +VIR_MIGRATE_OFFLINE = (1 << 10), /* offline migrate */
> } virDomainMigrateFlags;
>
> /* Domain migration. */
> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> index 97ad23e..38bfcab 100644
> --- a/src/qemu/qemu_driver.c
> +++ b/src/qemu/qemu_driver.c
> @@ -9622,6 +9622,20 @@ qemuDomainMigrateBegin3(virDomainPtr domain,
> }
>
> if (!virDomainObjIsActive(vm)) {
> +if (flags & VIR_MIGRATE_OFFLINE) {
> +if (flags & (VIR_MIGRATE_NON_SHARED_DISK|
> + VIR_MIGRATE_NON_SHARED_INC)) {
> +virReportError(VIR_ERR_OPERATION_INVALID,
> + "%s", _("migrating storage handled by volume
> APIs"));
> +goto endjob;
> +}
> +if (!(flags & VIR_MIGRATE_PERSIST_DEST)) {
> +virReportError(VIR_ERR_OPERATION_INVALID,
> + "%s", _("VIR_MIGRATE_OFFLINE should combined
> with VIR_MIGRATE_PERSIST_DEST"));
> +goto endjob;
> +}
> +goto offline;
> +}
> virReportError(VIR_ERR_OPERATION_INVALID,
> "%s", _("domain is not running"));
> goto endjob;
> @@ -9634,6 +9648,7 @@ qemuDomainMigrateBegin3(virDomainPtr domain,
> if (qemuDomainCheckEjectableMedia(driver, vm, asyncJob) < 0)
> goto endjob;
>
> +offline:
> if (!(xml = qemuMigrationBegin(driver, vm, xmlin, dname,
> cookieout, cookieoutlen,
> flags)))
> diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> index db69a0a..b2f921e 100644
> --- a/src/qemu/qemu_migration.c
> +++ b/src/qemu/qemu_migration.c
> @@ -70,6 +70,7 @@ enum qemuMigrationCookieFlags {
> QEMU_MIGRATION_COOKIE_FLAG_GRAPHICS,
> QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE,
> QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT,
> +QEMU_MIGRATION_COOKIE_FLAG_OFFLINE,
>
> QEMU_MIGRATION_COOKIE_FLAG_LAST
> };
> @@ -77,12 +78,13 @@ enum qemuMigrationCookieFlags {
> VIR_ENUM_DECL(qemuMigrationCookieFlag);
> VIR_ENUM_IMPL(qemuMigrationCookieFlag,
>QEMU_MIGRATION_COOKIE_FLAG_LAST,
> - "graphics", "lockstate", "persistent");
> + "graphics", "lockstate", "persistent", "offline");
>
> enum qemuMigrationCookieFeatures {
> QEMU_MIGRATION_COOKIE_GRAPHICS = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_GRAPHICS),
> QEMU_MIGRATION_COOKIE_LOCKSTATE = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE),
> QEMU_MIGRATION_COOKIE_PERSISTENT = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT),
> +QEMU_MIGRATION_COOKIE_OFFLINE = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_OFFLINE),
> };
>
> typedef struct _qemuMigrationCookieGraphics qemuMigrationCookieGraphics;
> @@ -439,6 +441,9 @@ qemuMigrationCookieXMLFormat(struct qemud_driver *driver,
> virBufferAdjustIndent(buf, -2);
> }
>
> +if (mig->flags & QEMU_MIGRATION_COOKIE_OFFLINE)
> +virBufferAsprintf(buf, " \n");
> +
> virBufferAddLit(buf, "\n");
> return 0;
> }
> @@ -662,6 +667,11 @@ qemuMigrationCookieXMLParse(qemuMigrationCookiePtr mig,
> VIR_FREE(nodes);
> }
>
> +if ((flags & QEMU_MIGRATION_COOKIE_OFFLINE)) {
> +if (virXPathBoolean("count(./offline) > 0", ctxt))
> +mig->flags |= QEMU_MIGRATION_COOKIE_OFFLINE;
> +}
> +
> return 0;
>
> error:
> @@ -721
Re: [libvirt] [PATCH RFC] helper of copy-storage-* features
在 2012-10-21日的 21:09 -0500，Doug Goldstein写道：
> On Sun, Oct 21, 2012 at 7:53 PM, liguang wrote:
> > help to create disk images copy-storage-* required,
> > try to do non-shared migration without bothering to
> > create disk images at target by hand.
> >
> > consider this situation:
> > 1. non-shared migration
> >virsh migrate --copy-storage-all ...
> > 2. migration fails
> > 3. create disk images required
> >qemu-img create ...
> > 4 migration run smoothly
> > so, try do remove step 2, 3, 4
> >
> > this kind of use had been discussed before,
> > http://www.redhat.com/archives/libvir-list/2011-December/msg00451.html
> >
> > maybe there're some flaws:
> > - It did not handle more about complete situations
> > suggested by Daniel P. Berrange,
> > https://www.redhat.com/archives/libvir-list/2012-October/msg00407.html
> > but may try to take care of them later.
> > so, now only normal disk image files be handled.
>
> The problem is it will silently blow up for people using LVM or other
> backend types which is definitely not ok. You should do preflight
> checks to ensure that you can handle all the disks before attempting
> the migration.
>
> > - for creation of disk images, size was setting as 0x boldly,
> > hope it can consolidate qemu, haven't constructed a comfortable
> > idea to solve it.
>
> What if the virtual disk coming over is larger? Will this go boom? Or
> are you expecting that qemu will resize? If you're expecting that qemu
> will resize it then you should likely only create the disk 1 block big
> or so. If not you need to send the sizes as part of the cookie.
>
> >
I don't know exactly what action qemu will take if pre-alloc is smaller,
sorry about it. my pre-allocation will only take small real disk space,
and hope it's greater than real disk space migration required.
pretty roughly way! or, any good idea about it?
but, I really don't want to take disk size from source to target.
> > Signed-off-by: liguang
> > ---
> > src/qemu/qemu_migration.c | 87
> > +++-
> > 1 files changed, 85 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> > index db69a0a..5c3ad9f 100644
> > --- a/src/qemu/qemu_migration.c
> > +++ b/src/qemu/qemu_migration.c
> > @@ -49,6 +49,7 @@
> > #include "storage_file.h"
> > #include "viruri.h"
> > #include "hooks.h"
> > +#include "dirname.h"
> >
> >
> > #define VIR_FROM_THIS VIR_FROM_QEMU
> > @@ -70,6 +71,7 @@ enum qemuMigrationCookieFlags {
> > QEMU_MIGRATION_COOKIE_FLAG_GRAPHICS,
> > QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE,
> > QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT,
> > +QEMU_MIGRATION_COOKIE_FLAG_COPYSTORAGE,
> >
> > QEMU_MIGRATION_COOKIE_FLAG_LAST
> > };
> > @@ -77,12 +79,13 @@ enum qemuMigrationCookieFlags {
> > VIR_ENUM_DECL(qemuMigrationCookieFlag);
> > VIR_ENUM_IMPL(qemuMigrationCookieFlag,
> >QEMU_MIGRATION_COOKIE_FLAG_LAST,
> > - "graphics", "lockstate", "persistent");
> > + "graphics", "lockstate", "persistent", "copystorage");
> >
> > enum qemuMigrationCookieFeatures {
> > QEMU_MIGRATION_COOKIE_GRAPHICS = (1 <<
> > QEMU_MIGRATION_COOKIE_FLAG_GRAPHICS),
> > QEMU_MIGRATION_COOKIE_LOCKSTATE = (1 <<
> > QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE),
> > QEMU_MIGRATION_COOKIE_PERSISTENT = (1 <<
> > QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT),
> > +QEMU_MIGRATION_COOKIE_COPYSTORAGE = (1 <<
> > QEMU_MIGRATION_COOKIE_FLAG_COPYSTORAGE),
> > };
> >
> > typedef struct _qemuMigrationCookieGraphics qemuMigrationCookieGraphics;
> > @@ -439,6 +442,9 @@ qemuMigrationCookieXMLFormat(struct qemud_driver
> > *driver,
> > virBufferAdjustIndent(buf, -2);
> > }
> >
> > +if (mig->flags & QEMU_MIGRATION_COOKIE_COPYSTORAGE)
> > +virBufferAsprintf(buf, " \n");
> > +
> > virBufferAddLit(buf, "\n");
> > return 0;
> > }
> > @@ -662,6 +668,11 @@ qemuMigrationCookieXMLParse(qemuMigrationCookiePtr mig,
> > VIR_FREE(nodes);
> > }
> >
> > +if ((flags & QEMU_MIGRATION_COOKIE_COPYSTORAGE)) {
> > +if (virXPathBoolean("count(./copystorage) > 0", ctxt))
> > +mig->flags |= QEMU_MIGRATION_COOKIE_COPYSTORAGE;
> > +}
> > +
> > return 0;
> >
> > error:
> > @@ -721,6 +732,9 @@ qemuMigrationBakeCookie(qemuMigrationCookiePtr mig,
> > qemuMigrationCookieAddPersistent(mig, dom) < 0)
> > return -1;
> >
> > +if (flags & QEMU_MIGRATION_COOKIE_COPYSTORAGE)
> > +mig->flags |= QEMU_MIGRATION_COOKIE_COPYSTORAGE;
> > +
> > if (!(*cookieout = qemuMigrationCookieXMLFormatStr(driver, mig)))
> > return -1;
> >
> > @@ -1168,6 +1182,14 @@ char *qemuMigrationBegin(struct qemud_driver *driver,
> > QEMU_MIGRATION_COOKIE_LOCKSTATE) < 0)
> > goto cleanup;
> >
> > +if (flags & (VIR_MIGRATE_NON_SHARED_DISK |
> > + VIR_MIGRA
Re: [libvirt] [PATCH][RFC] helper of copy-storage-* features
在 2012-10-18四的 06:52 -0600，Eric Blake写道：
> On 10/17/2012 08:50 PM, Doug Goldstein wrote:
> > On Sun, Oct 14, 2012 at 9:48 PM, liguang wrote:
> >> help to create disk images copy-storage-* required,
> >> try to do non-shared migration without bothering to
> >> create disk images at target by hand.
> >>
>
> >> +char *virDirOfFile(const char *file)
>
> Poor naming. Better might be virDirName, to match what we are wrapping.
>
> >> +{
> >> +char *p, *tmp;
> >> +
> >> +if (file == NULL)
> >> +return NULL;
> >> +if ((tmp = strdup(file)) == NULL)
> >> +return NULL;
> >> +if ((p = strrchr(file, '/')) == NULL)
> >> +return getcwd(tmp, strlen(file));
> >> +if (strlen(p) == 0)
> >> +return NULL;
> >> +tmp[strlen(file) - strlen(p)] = '\0';
> >> +
> >> +return tmp;
> >> +}
> >
> > Eric probably knows better than I do but it seems like we can probably
> > pull in dirname() from gnulib for this rather than implementing our
> > own version.
>
> 'git grep mdir_name' - we're already using the gnulib interface in two
> places. It does not handle NULL input, but that would imply you just write:
>
> char *
> virDirName(const char *file)
> {
> if (!file)
> return NULL;
> return mdir_name(file);
> }
>
> and let the caller deal with NULL return. Then again, if the caller is
> going to virReportOOMError(), it may be better to just use mdir_name()
> directly, and guarantee that the caller doesn't pass in NULL in the
> first place.
>
OK, I'll use mdir_name directly, new patch will come up later.
Thanks!
--
liguanglig.f...@cn.fujitsu.com
FNST linux kernel team
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH][RFC] helper of copy-storage-* features
在 2012-10-18四的 01:03 -0500，Doug Goldstein写道：
> On Thu, Oct 18, 2012 at 12:47 AM, li guang wrote:
> > 在 2012-10-17三的 21:50 -0500，Doug Goldstein写道：
> >> On Sun, Oct 14, 2012 at 9:48 PM, liguang wrote:
> >> > help to create disk images copy-storage-* required,
> >> > try to do non-shared migration without bothering to
> >> > create disk images at target by hand.
> >> >
> >> > consider this situation:
> >> > 1. non-shared migration
> >> >virsh migrate --copy-storage-all ...
> >> > 2. migration fails
> >> > 3. create disk images required
> >> >qemu-img create ...
> >> > 4 migration run smoothly
> >> > so, try do remove step 2, 3, 4
> >> >
> >> > +char *virDirOfFile(const char *file)
> >> > +{
> >> > +char *p, *tmp;
> >> > +
> >> > +if (file == NULL)
> >> > +return NULL;
> >> > +if ((tmp = strdup(file)) == NULL)
> >> > +return NULL;
> >> > +if ((p = strrchr(file, '/')) == NULL)
> >> > +return getcwd(tmp, strlen(file));
> >> > +if (strlen(p) == 0)
> >> > +return NULL;
> >> > +tmp[strlen(file) - strlen(p)] = '\0';
> >> > +
> >> > +return tmp;
> >> > +}
> >>
> >> Eric probably knows better than I do but it seems like we can probably
> >> pull in dirname() from gnulib for this rather than implementing our
> >> own version.
> >>
> >
> > maybe, but dirname has its own known issues(e.g. for old version glibc,
> > dirname will "generate a segfault if given a NULL argument"), so I
> > try to choose a loosely implementation.
> > but, if libvirt cares nothing about these tiny issues, I'd like
> > to choose dirname.
>
> That's why I'm suggesting to use dirname from gnulib, which fixes
> several of those issues. Additionally the implementation above
> wouldn't work on Windows, not that we currently build the libvirtd on
> Windows but if the function was used in the future the function would
> have to be fixed.
glad to hear that gnulib's dirname is a fixed version,
if so, I'd like to use it instead of my silly re-implementation.
Thanks!
>
> >
> >> > diff --git a/src/util/util.h b/src/util/util.h
> >> > index 4316ab1..255b7b2 100644
> >> > --- a/src/util/util.h
> >> > +++ b/src/util/util.h
> >> > @@ -114,6 +114,7 @@ enum {
> >> > };
> >> > int virDirCreate(const char *path, mode_t mode, uid_t uid, gid_t gid,
> >> > unsigned int flags) ATTRIBUTE_RETURN_CHECK;
> >> > +char *virDirOfFile(const char *file) ATTRIBUTE_RETURN_CHECK;
> >> > int virFileMakePath(const char *path) ATTRIBUTE_RETURN_CHECK;
> >> > int virFileMakePathWithMode(const char *path,
> >> > mode_t mode) ATTRIBUTE_RETURN_CHECK;
> >> > --
> >> > 1.7.2.5
> >> >
> >> > --
> >> > libvir-list mailing list
> >> > libvir-list@redhat.com
> >> > https://www.redhat.com/mailman/listinfo/libvir-list
> >>
> >>
> >>
> >
> > --
> > liguanglig.f...@cn.fujitsu.com
> > FNST linux kernel team
> >
>
--
liguanglig.f...@cn.fujitsu.com
FNST linux kernel team
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH][RFC] helper of copy-storage-* features
在 2012-10-17三的 21:50 -0500，Doug Goldstein写道：
> On Sun, Oct 14, 2012 at 9:48 PM, liguang wrote:
> > help to create disk images copy-storage-* required,
> > try to do non-shared migration without bothering to
> > create disk images at target by hand.
> >
> > consider this situation:
> > 1. non-shared migration
> >virsh migrate --copy-storage-all ...
> > 2. migration fails
> > 3. create disk images required
> >qemu-img create ...
> > 4 migration run smoothly
> > so, try do remove step 2, 3, 4
> >
> > +char *virDirOfFile(const char *file)
> > +{
> > +char *p, *tmp;
> > +
> > +if (file == NULL)
> > +return NULL;
> > +if ((tmp = strdup(file)) == NULL)
> > +return NULL;
> > +if ((p = strrchr(file, '/')) == NULL)
> > +return getcwd(tmp, strlen(file));
> > +if (strlen(p) == 0)
> > +return NULL;
> > +tmp[strlen(file) - strlen(p)] = '\0';
> > +
> > +return tmp;
> > +}
>
> Eric probably knows better than I do but it seems like we can probably
> pull in dirname() from gnulib for this rather than implementing our
> own version.
>
maybe, but dirname has its own known issues(e.g. for old version glibc,
dirname will "generate a segfault if given a NULL argument"), so I
try to choose a loosely implementation.
but, if libvirt cares nothing about these tiny issues, I'd like
to choose dirname.
> > diff --git a/src/util/util.h b/src/util/util.h
> > index 4316ab1..255b7b2 100644
> > --- a/src/util/util.h
> > +++ b/src/util/util.h
> > @@ -114,6 +114,7 @@ enum {
> > };
> > int virDirCreate(const char *path, mode_t mode, uid_t uid, gid_t gid,
> > unsigned int flags) ATTRIBUTE_RETURN_CHECK;
> > +char *virDirOfFile(const char *file) ATTRIBUTE_RETURN_CHECK;
> > int virFileMakePath(const char *path) ATTRIBUTE_RETURN_CHECK;
> > int virFileMakePathWithMode(const char *path,
> > mode_t mode) ATTRIBUTE_RETURN_CHECK;
> > --
> > 1.7.2.5
> >
> > --
> > libvir-list mailing list
> > libvir-list@redhat.com
> > https://www.redhat.com/mailman/listinfo/libvir-list
>
>
>
--
liguanglig.f...@cn.fujitsu.com
FNST linux kernel team
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH][RFC] helper of copy-storage-* features
ping ...
在 2012-10-15一的 10:48 +0800，liguang写道：
> help to create disk images copy-storage-* required,
> try to do non-shared migration without bothering to
> create disk images at target by hand.
>
> consider this situation:
> 1. non-shared migration
>virsh migrate --copy-storage-all ...
> 2. migration fails
> 3. create disk images required
>qemu-img create ...
> 4 migration run smoothly
> so, try do remove step 2, 3, 4
>
> this kind of use had been discussed before,
> http://www.redhat.com/archives/libvir-list/2011-December/msg00451.html
>
> It did not handle more about complete situations
> suggested by Daniel P. Berrange,
> https://www.redhat.com/archives/libvir-list/2012-October/msg00407.html
>
> Signed-off-by: liguang
> ---
> src/libvirt_private.syms |1 +
> src/qemu/qemu_migration.c | 92 +++-
> src/util/util.c | 17
> src/util/util.h |1 +
> 4 files changed, 108 insertions(+), 3 deletions(-)
>
> diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
> index a8c81e7..a293184 100644
> --- a/src/libvirt_private.syms
> +++ b/src/libvirt_private.syms
> @@ -1202,6 +1202,7 @@ virArgvToString;
> virAsprintf;
> virBuildPathInternal;
> virDirCreate;
> +virDirOfFile;
> virDoubleToStr;
> virEnumFromString;
> virEnumToString;
> diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> index db69a0a..ac3e1c3 100644
> --- a/src/qemu/qemu_migration.c
> +++ b/src/qemu/qemu_migration.c
> @@ -70,6 +70,7 @@ enum qemuMigrationCookieFlags {
> QEMU_MIGRATION_COOKIE_FLAG_GRAPHICS,
> QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE,
> QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT,
> +QEMU_MIGRATION_COOKIE_FLAG_COPYSTORAGE,
>
> QEMU_MIGRATION_COOKIE_FLAG_LAST
> };
> @@ -77,12 +78,13 @@ enum qemuMigrationCookieFlags {
> VIR_ENUM_DECL(qemuMigrationCookieFlag);
> VIR_ENUM_IMPL(qemuMigrationCookieFlag,
>QEMU_MIGRATION_COOKIE_FLAG_LAST,
> - "graphics", "lockstate", "persistent");
> + "graphics", "lockstate", "persistent", "copystorage");
>
> enum qemuMigrationCookieFeatures {
> QEMU_MIGRATION_COOKIE_GRAPHICS = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_GRAPHICS),
> QEMU_MIGRATION_COOKIE_LOCKSTATE = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE),
> QEMU_MIGRATION_COOKIE_PERSISTENT = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT),
> +QEMU_MIGRATION_COOKIE_COPYSTORAGE = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_COPYSTORAGE),
> };
>
> typedef struct _qemuMigrationCookieGraphics qemuMigrationCookieGraphics;
> @@ -439,6 +441,10 @@ qemuMigrationCookieXMLFormat(struct qemud_driver *driver,
> virBufferAdjustIndent(buf, -2);
> }
>
> +if (mig->flags & QEMU_MIGRATION_COOKIE_COPYSTORAGE)
> +virBufferAsprintf(buf, " \n");
> +
> +
> virBufferAddLit(buf, "\n");
> return 0;
> }
> @@ -662,6 +668,11 @@ qemuMigrationCookieXMLParse(qemuMigrationCookiePtr mig,
> VIR_FREE(nodes);
> }
>
> +if ((flags & QEMU_MIGRATION_COOKIE_COPYSTORAGE)) {
> +if (virXPathBoolean("count(./copystorage) > 0", ctxt))
> +mig->flags |= QEMU_MIGRATION_COOKIE_COPYSTORAGE;
> +}
> +
> return 0;
>
> error:
> @@ -1215,6 +1226,60 @@ qemuMigrationPrepareCleanup(struct qemud_driver
> *driver,
> qemuDomainObjDiscardAsyncJob(driver, vm);
> }
>
> +static int qemuMigrationHandleDiskFiles(const char *dom_xml, int pin)
> +{
> +xmlDocPtr doc = NULL;
> +xmlXPathContextPtr ctxt = NULL;
> +xmlNodePtr *disks = NULL;
> +virCommandPtr cmd = NULL;
> +int i, nr, ret = -1;
> +char *file_name[] = {}, *file_fmt[] = {};
> +char *driver_name, *tmp_dir;
> +
> +if (!(doc = virXMLParseStringCtxt(dom_xml, _("(domain_definition)"),
> &ctxt)))
> +goto cleanup;
> +
> +if ((nr = virXPathNodeSet("./devices/disk", ctxt, &disks)) <= 0)
> +goto cleanup;
> +
> +for (i = 0; i < nr; i++) {
> +ctxt->node = disks[i];
> +driver_name = virXPathString("string(./driver/@name)", ctxt);
> +if (STRNEQ(driver_name, "qemu"))
> +continue;
> +file_fmt[i] = virXPathString("string(./driver/@type)", ctxt);
> +file_name[i] = virXPathString("string(./source/file)", ctxt);
> +if (virFileExists(file_name[i]) && !pin)
> +continue;
> +if ((tmp_dir = virDirOfFile(file_name[i])) == NULL)
> +continue;
> +if (!virFileExists(tmp_dir))
> +if (virFileMakePath(tmp_dir) < 0)
> +continue;
> +if (pin)
> +cmd = virCommandNewArgList("qemu-img", "create", "-f",
> + file_fmt[i], file_name[i], ~0UL,
> NULL);
> +else
> +cmd = virCommandNewArgList("rm", "-f", file_name[i], NULL);
> +if (virCommandRun(cmd, NULL) < 0) {
> +goto cleanup;
> +virReportSystemError(errno, "%s",
> +
Re: [libvirt] [PATCH v10] support offline migration
在 2012-10-16二的 13:19 +0100，Daniel P. Berrange写道： > On Thu, Oct 11, 2012 at 12:17:56PM +0800, liguang wrote: > > original migration did not aware of offline case, > > so, try to support offline migration quietly > > (did not disturb original migration) by pass > > VIR_MIGRATE_OFFLINE flag to migration APIs if only > > the domain is really inactive, and > > migration process will not puzzled by domain > > offline and exit unexpectedly. > > these changes did not take care of disk images the > > domain required, for them could be transferred by > > other APIs as suggested, then VIR_MIGRATE_OFFLINE > > should not combined with VIR_MIGRATE_NON_SHARED_*. > > if you want a persistent migration, > > you should do "virsh migrate --persistent" youself. > > > > Signed-off-by: liguang > > This is still not quite working correctly. The following command > must *not* run > > # virsh -c qemu+ssh://root@avocado/system migrate vm1 --offline > qemu+ssh://root@mustard/system > > because it does not include the '--persistent' flag. > > If I do set the --persistent flag though, that is now > correctly operating. Likewise --undefinesource is > working now. > > The other bug remaining is that you are still creating > an XML file /var/run/libvirt/qemu/$GUESTNAME.xml for > the inactive guest. This is bogus, because that file > should only exist if the guest is running. > > Daniel OK, I'll fix-up as you said, thanks! -- liguanglig.f...@cn.fujitsu.com FNST linux kernel team -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v10] support offline migration
ping ...
在 2012-10-11四的 12:17 +0800，liguang写道：
> original migration did not aware of offline case,
> so, try to support offline migration quietly
> (did not disturb original migration) by pass
> VIR_MIGRATE_OFFLINE flag to migration APIs if only
> the domain is really inactive, and
> migration process will not puzzled by domain
> offline and exit unexpectedly.
> these changes did not take care of disk images the
> domain required, for them could be transferred by
> other APIs as suggested, then VIR_MIGRATE_OFFLINE
> should not combined with VIR_MIGRATE_NON_SHARED_*.
> if you want a persistent migration,
> you should do "virsh migrate --persistent" youself.
>
> Signed-off-by: liguang
> ---
> include/libvirt/libvirt.h.in |1 +
> src/qemu/qemu_driver.c | 10
> src/qemu/qemu_migration.c| 52
> +-
> src/qemu/qemu_migration.h|3 +-
> tools/virsh-domain.c |6 +
> 5 files changed, 65 insertions(+), 7 deletions(-)
>
> diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
> index 81f12a4..1cebc21 100644
> --- a/include/libvirt/libvirt.h.in
> +++ b/include/libvirt/libvirt.h.in
> @@ -995,6 +995,7 @@ typedef enum {
> * whole migration process;
> this will be used automatically
> * when supported */
> VIR_MIGRATE_UNSAFE= (1 << 9), /* force migration even if it
> is considered unsafe */
> +VIR_MIGRATE_OFFLINE = (1 << 10), /* offline migrate */
> } virDomainMigrateFlags;
>
> /* Domain migration. */
> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> index 97ad23e..6189bbe 100644
> --- a/src/qemu/qemu_driver.c
> +++ b/src/qemu/qemu_driver.c
> @@ -9622,6 +9622,15 @@ qemuDomainMigrateBegin3(virDomainPtr domain,
> }
>
> if (!virDomainObjIsActive(vm)) {
> +if (flags & VIR_MIGRATE_OFFLINE) {
> +if (flags & (VIR_MIGRATE_NON_SHARED_DISK|
> + VIR_MIGRATE_NON_SHARED_INC)) {
> +virReportError(VIR_ERR_OPERATION_INVALID,
> + "%s", _("migrating storage handled by volume
> APIs"));
> +goto endjob;
> +}
> +goto offline;
> +}
> virReportError(VIR_ERR_OPERATION_INVALID,
> "%s", _("domain is not running"));
> goto endjob;
> @@ -9634,6 +9643,7 @@ qemuDomainMigrateBegin3(virDomainPtr domain,
> if (qemuDomainCheckEjectableMedia(driver, vm, asyncJob) < 0)
> goto endjob;
>
> +offline:
> if (!(xml = qemuMigrationBegin(driver, vm, xmlin, dname,
> cookieout, cookieoutlen,
> flags)))
> diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> index db69a0a..6845a97 100644
> --- a/src/qemu/qemu_migration.c
> +++ b/src/qemu/qemu_migration.c
> @@ -70,6 +70,7 @@ enum qemuMigrationCookieFlags {
> QEMU_MIGRATION_COOKIE_FLAG_GRAPHICS,
> QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE,
> QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT,
> +QEMU_MIGRATION_COOKIE_FLAG_OFFLINE,
>
> QEMU_MIGRATION_COOKIE_FLAG_LAST
> };
> @@ -77,12 +78,13 @@ enum qemuMigrationCookieFlags {
> VIR_ENUM_DECL(qemuMigrationCookieFlag);
> VIR_ENUM_IMPL(qemuMigrationCookieFlag,
>QEMU_MIGRATION_COOKIE_FLAG_LAST,
> - "graphics", "lockstate", "persistent");
> + "graphics", "lockstate", "persistent", "offline");
>
> enum qemuMigrationCookieFeatures {
> QEMU_MIGRATION_COOKIE_GRAPHICS = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_GRAPHICS),
> QEMU_MIGRATION_COOKIE_LOCKSTATE = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE),
> QEMU_MIGRATION_COOKIE_PERSISTENT = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT),
> +QEMU_MIGRATION_COOKIE_OFFLINE = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_OFFLINE),
> };
>
> typedef struct _qemuMigrationCookieGraphics qemuMigrationCookieGraphics;
> @@ -439,6 +441,9 @@ qemuMigrationCookieXMLFormat(struct qemud_driver *driver,
> virBufferAdjustIndent(buf, -2);
> }
>
> +if (mig->flags & QEMU_MIGRATION_COOKIE_OFFLINE)
> +virBufferAsprintf(buf, " \n");
> +
> virBufferAddLit(buf, "\n");
> return 0;
> }
> @@ -662,6 +667,11 @@ qemuMigrationCookieXMLParse(qemuMigrationCookiePtr mig,
> VIR_FREE(nodes);
> }
>
> +if ((flags & QEMU_MIGRATION_COOKIE_OFFLINE)) {
> +if (virXPathBoolean("count(./offline) > 0", ctxt))
> +mig->flags |= QEMU_MIGRATION_COOKIE_OFFLINE;
> +}
> +
> return 0;
>
> error:
> @@ -721,6 +731,10 @@ qemuMigrationBakeCookie(qemuMigrationCookiePtr mig,
> qemuMigrationCookieAddPersistent(mig, dom) < 0)
> return -1;
>
> +if (flags & QEMU_MIGRATION_COOKIE_OFFLINE) {
> +mig->flags |= QEMU_MIGRATION_COOKIE_OFFLINE;
> +}
> +
> if
Re: [libvirt] [PATCH] remove unnecessary eat-cookie
ping ...
在 2012-10-11四的 12:17 +0800，liguang写道：
> located at qemuMigrationConfirm
>
> Signed-off-by: liguang
> ---
> src/qemu/qemu_migration.c |4
> 1 files changed, 0 insertions(+), 4 deletions(-)
>
> diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> index 6845a97..26aacaf 100644
> --- a/src/qemu/qemu_migration.c
> +++ b/src/qemu/qemu_migration.c
> @@ -3157,7 +3157,6 @@ int qemuMigrationConfirm(struct qemud_driver *driver,
> unsigned int flags,
> int retcode)
> {
> -qemuMigrationCookiePtr mig;
> virDomainEventPtr event = NULL;
> int rv = -1;
> VIR_DEBUG("driver=%p, conn=%p, vm=%p, cookiein=%s, cookieinlen=%d, "
> @@ -3172,8 +3171,6 @@ int qemuMigrationConfirm(struct qemud_driver *driver,
> ? QEMU_MIGRATION_PHASE_CONFIRM3
> : QEMU_MIGRATION_PHASE_CONFIRM3_CANCELLED);
>
> -if (!(mig = qemuMigrationEatCookie(driver, vm, cookiein, cookieinlen,
> 0)))
> -return -1;
> if (flags & VIR_MIGRATE_OFFLINE)
> goto offline;
>
> @@ -3213,7 +3210,6 @@ int qemuMigrationConfirm(struct qemud_driver *driver,
> }
>
> offline:
> -qemuMigrationCookieFree(mig);
> rv = 0;
>
> cleanup:
--
liguanglig.f...@cn.fujitsu.com
FNST linux kernel team
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [re-send][PATCH 1/3] add qemu driver hook
在 2012-10-10三的 15:00 +0100，Daniel P. Berrange写道： > On Mon, Oct 08, 2012 at 08:05:21PM -0600, Eric Blake wrote: > > On 10/08/2012 07:51 PM, liguang wrote: > > > this hook aimed at migration only, it supposed > > > to be used as a helper of migrate --copy-storage-* > > > features to remove the unreasonable limitation > > > of pre-exist disk images at migration target. > > > someone can add more functions to hook files. > > > > NACK. Instead of writing a hook that runs outside of libvirt and has to > > be installed to be of use, we should instead fix libvirt to do the file > > creation itself. That is, you should be patching > > src/qemu/qemu_migration.c to detect when copy-storage-* has been passed, > > and to then pre-create the proper empty files and give them correct > > SELinux labels. > > Correctly doing auto-creation of disk images on the target host is > alot more complicated that you might assume, and the hook script > here misses alot of the hard bits > > - If the migration fails, you need to clean up these disk images >you just created, because the data in them may be incomplete >or corrupt. > > - If the source image is using encryption, then the target image >should use encryption too > > - If the source image uses a backing file, then when incremental >copy is requested, we might need to maintain the backing store. > > - if the migration API did not have either of the --copy-* >flags set we should not be doing any creation of disk images > > - We need to handling of non-file based disk images, because >even block devices may be local-only. > > - If the user passed a custom XML for the target that differs >from the source, this may affect decisions we need to make >above wrt encryption or backing files > > Finally, we should *not* do auto-creation by default - we need to > add a new migrate flag to allow apps to turn it on, only if they > want it. > > Daniel perfect consideration! suppose this situation, I create disk images qemu needed at target by qemu-img create -f 'format' 'image' 'size', then virsh migrate --copy-storage-* everything runs smoothly, so, as i stated before, this patch limited to create-image-by-hand alleviation. -- liguanglig.f...@cn.fujitsu.com FNST linux kernel team -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v9] support offline migration
在 2012-10-10三的 14:38 +0100，Daniel P. Berrange写道： > On Tue, Sep 25, 2012 at 03:45:24PM +0800, liguang wrote: > > original migration did not aware of offline case, > > so, try to support offline migration quietly > > (did not disturb original migration) by pass > > VIR_MIGRATE_OFFLINE flag to migration APIs if only > > the domain is really inactive, and > > migration process will not puzzled by domain > > offline and exit unexpectedly. > > these changes did not take care of disk images the > > domain required, for them could be transferred by > > other APIs as suggested, then VIR_MIGRATE_OFFLINE > > should not combined with VIR_MIGRATE_NON_SHARED_*. > > so, this migration result is just make domain > > definition alive at target side. > > > > Signed-off-by: liguang > > --- > > include/libvirt/libvirt.h.in |1 + > > src/qemu/qemu_driver.c | 15 > > src/qemu/qemu_migration.c| 53 > > - > > src/qemu/qemu_migration.h|3 +- > > tools/virsh-domain.c |6 > > 5 files changed, 70 insertions(+), 8 deletions(-) > > In my testing this patch is still badly broken, apparently no different > than the previous version I tested > > I have 2 hosts, avocado & mustard and stopped guest vm1. I try to > migrate the VM from avocado to mustard thus: > > # ./tools/virsh -c qemu+ssh://root@avocado/system migrate --undefinesource > --offline vm1 qemu+ssh://root@mustard/system > > This should *not* even run because I did not pass the --persistent flag, > but it does in fact complete. I creates a guest 'vm1' on the target host, > but does not write out any config. This is a completely bogus scenario. > If a guest has no config, it is transient and thus must not exist if it > is shutoff, but your patch is resulting in a transient, shutoff guest. > > If I set the '--persistent' flag, there is no diffrence in behaviour. We > still get a transient shutoff guest on the target. pretty logical requirement, actually, you've got it located at for example /var/run/libvirt/qemu/dom.xml, and it's really persistent. I'll try to save config normally. > > Also the '--undefinesource' flag appeared to have no effect at all. The > guest still exists on the source, both in libvirtd & on disk. > Yes, I did fail to take care of it, thanks! > > Daniel -- liguanglig.f...@cn.fujitsu.com FNST linux kernel team -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [re-send][PATCH v9] support offline migration
ping ...
在 2012-10-08一的 09:20 +0800，li guang写道：
> ping ...
>
> 在 2012-09-28五的 11:48 +0800，liguang写道：
> > original migration did not aware of offline case,
> > so, try to support offline migration quietly
> > (did not disturb original migration) by pass
> > VIR_MIGRATE_OFFLINE flag to migration APIs if only
> > the domain is really inactive, and
> > migration process will not puzzled by domain
> > offline and exit unexpectedly.
> > these changes did not take care of disk images the
> > domain required, for them could be transferred by
> > other APIs as suggested, then VIR_MIGRATE_OFFLINE
> > should not combined with VIR_MIGRATE_NON_SHARED_*.
> > so, this migration result is just make domain
> > definition alive at target side.
> >
> > Signed-off-by: liguang
> > ---
> > include/libvirt/libvirt.h.in |1 +
> > src/qemu/qemu_driver.c | 15
> > src/qemu/qemu_migration.c| 53
> > -
> > src/qemu/qemu_migration.h|3 +-
> > tools/virsh-domain.c |6
> > 5 files changed, 70 insertions(+), 8 deletions(-)
> >
> > diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
> > index 79c7689..627e9d4 100644
> > --- a/include/libvirt/libvirt.h.in
> > +++ b/include/libvirt/libvirt.h.in
> > @@ -995,6 +995,7 @@ typedef enum {
> > * whole migration process;
> > this will be used automatically
> > * when supported */
> > VIR_MIGRATE_UNSAFE= (1 << 9), /* force migration even if
> > it is considered unsafe */
> > +VIR_MIGRATE_OFFLINE = (1 << 10), /* offline migrate */
> > } virDomainMigrateFlags;
> >
> > /* Domain migration. */
> > diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> > index 6848924..105febf 100644
> > --- a/src/qemu/qemu_driver.c
> > +++ b/src/qemu/qemu_driver.c
> > @@ -9631,6 +9631,15 @@ qemuDomainMigrateBegin3(virDomainPtr domain,
> > }
> >
> > if (!virDomainObjIsActive(vm)) {
> > +if (flags & VIR_MIGRATE_OFFLINE) {
> > +if (flags & (VIR_MIGRATE_NON_SHARED_DISK|
> > + VIR_MIGRATE_NON_SHARED_INC)) {
> > +virReportError(VIR_ERR_OPERATION_INVALID,
> > + "%s", _("migrating storage handled by
> > volume APIs"));
> > +goto endjob;
> > +}
> > +goto offline;
> > +}
> > virReportError(VIR_ERR_OPERATION_INVALID,
> > "%s", _("domain is not running"));
> > goto endjob;
> > @@ -9643,6 +9652,7 @@ qemuDomainMigrateBegin3(virDomainPtr domain,
> > if (qemuDomainCheckEjectableMedia(driver, vm, asyncJob) < 0)
> > goto endjob;
> >
> > +offline:
> > if (!(xml = qemuMigrationBegin(driver, vm, xmlin, dname,
> > cookieout, cookieoutlen,
> > flags)))
> > @@ -9878,6 +9888,11 @@ qemuDomainMigrateConfirm3(virDomainPtr domain,
> > goto cleanup;
> > }
> >
> > +if (flags & VIR_MIGRATE_OFFLINE) {
> > +ret = 0;
> > +goto cleanup;
> > +}
> > +
> > if (!qemuMigrationJobIsActive(vm, QEMU_ASYNC_JOB_MIGRATION_OUT))
> > goto cleanup;
> >
> > diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> > index 8e85875..411a4c2 100644
> > --- a/src/qemu/qemu_migration.c
> > +++ b/src/qemu/qemu_migration.c
> > @@ -70,6 +70,7 @@ enum qemuMigrationCookieFlags {
> > QEMU_MIGRATION_COOKIE_FLAG_GRAPHICS,
> > QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE,
> > QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT,
> > +QEMU_MIGRATION_COOKIE_FLAG_OFFLINE,
> >
> > QEMU_MIGRATION_COOKIE_FLAG_LAST
> > };
> > @@ -77,12 +78,13 @@ enum qemuMigrationCookieFlags {
> > VIR_ENUM_DECL(qemuMigrationCookieFlag);
> > VIR_ENUM_IMPL(qemuMigrationCookieFlag,
> >QEMU_MIGRATION_COOKIE_FLAG_LAST,
> > - "graphics", "lockstate", "persistent");
> > + "graphics", "lockstate", "persistent", "offline");
> >
> > enum qemuMigrationCookieFeatures {
> > QEMU_MIGRATION_COOKIE_GRAPHICS = (1 <<
Re: [libvirt] [re-send][PATCH 1/3] add qemu driver hook
在 2012-10-08一的 21:54 -0600，Eric Blake写道： > On 10/08/2012 08:33 PM, li guang wrote: > > 在 2012-10-08一的 20:05 -0600，Eric Blake写道： > >> On 10/08/2012 07:51 PM, liguang wrote: > >>> this hook aimed at migration only, it supposed > >>> to be used as a helper of migrate --copy-storage-* > >>> features to remove the unreasonable limitation > >>> of pre-exist disk images at migration target. > >>> someone can add more functions to hook files. > >> > >> NACK. Instead of writing a hook that runs outside of libvirt and has to > >> be installed to be of use, we should instead fix libvirt to do the file > >> creation itself. That is, you should be patching > >> src/qemu/qemu_migration.c to detect when copy-storage-* has been passed, > > > > really? sorry, I don't know any implicit libvirt development rules, > > but, as I see, there are none hooks used by libvirt until now, why > > don't we use them instead of just design and obsolete? > > The problem with doing this as a python hook instead of directly in the > libvirt code is that you still got the sVirt SELinux labeling wrong. > Really, the file MUST be created by the libvirt C code, as that is the > code that knows what SELinux label to apply to the new file. > Furthermore, hooks are reserved for the user. We should not be making > libvirt rely on the installation of hooks for correct operation of the > normal case. > > > can't hooks be installed just like other libvirt files? > > then, create files by python or c have difference? > > Hooks are limited in what they can do - they are documented as being > unable to call back in to other libvirt calls. They are also less > efficient - why spawn a python process, when we already have all the > information to create the file in C code? > > Ultimately, I'd like to see this wart of --copy-storage fixed, but fixed > properly in the C code and not by adding a hook file. > OK, I see, thanks a lot! -- liguanglig.f...@cn.fujitsu.com FNST linux kernel team -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [re-send][PATCH 2/3] use WIFEXITED macro to see exit status of child
在 2012-10-08一的 21:05 -0600，Eric Blake写道：
> On 10/08/2012 08:51 PM, li guang wrote:
> > 在 2012-10-08一的 20:05 -0600，Eric Blake写道：
> >> On 10/08/2012 07:51 PM, liguang wrote:
> >>> this usage was suggested by man-page of waitpid,
> >>> returns true if the child terminated normally
> >>
> >> NACK. virCommandRun already did this for you.
> >
> > right, but not exactly,
> > virCommandRun will leave raw exit-status out of there,
>
> Ah, after re-reading the code, so it does (I had thought we changed it
> to guarantee a return of -1 on any !WIFEXITED() exit, and a sanitized
> WEXITSTATUS() value, rather than making all the callers do that, but I
> guess not).
>
> > so if the waited-command exit with a code '1',
> > then the caller of virCommandRun will see exit-status
> > value 0x100, and report an odd '256' exit-status.
>
> That depends on your OS. There are some systems out there where normal
> exit is in the low-order rather than high-order byte. But that's why we
> have virProcessTranslateStatus(), to do the work correctly.
virProcessTranslateStatus seems just a int to string translation
>
> >>> ret = virCommandRun(cmd, &exitstatus);
> >>> -if (ret == 0 && exitstatus != 0) {
> >>> +if (ret == 0 && WIFEXITED(exitstatus) == 0) {
>
> You have a logic bug - the old code was checking for non-zero status,
> and you switched it to check for zero status.
>
'WIFEXITED(exitstatus) == 0' means waited-command exit unexpectedly, so,
report error, my thought is try to ignore the normal 'exit(x)'s x value'
returned by waited-command.
> >>> virReportError(VIR_ERR_HOOK_SCRIPT_FAILED,
> >>> _("Hook script %s %s failed with error code %d"),
> >>> path, drvstr, exitstatus);
>
> This is not a correct error message - if you ever use WIFEXITED, you
> must also use WEXITSTATUS, otherwise you have a mismatch. And for this
> particular error message, I think we are losing useful information; I
> argue that we'd probably get a much better error message if we changed
> this to let virCommandRun do ALL the work:
>
> ret = virCommandRun(cmd, NULL);
>
--
liguanglig.f...@cn.fujitsu.com
FNST linux kernel team
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] fix-up an implicit build dead-loop in cfg.mk
在 2012-10-08一的 20:13 -0600，Eric Blake写道： > On 09/28/2012 06:25 AM, Eric Blake wrote: > > On 09/27/2012 09:51 PM, liguang wrote: > >> if gnulib submodule happened to be dirty, build > >> process will fall into '_autogen' target trap > >> in cfg.mk recursively, so break this dead-loop. > > > > Yes, I've run into this before; thanks for trying to tackle it. > > > >> > >> Signed-off-by: liguang > >> --- > >> cfg.mk |2 +- > >> 1 files changed, 1 insertions(+), 1 deletions(-) > >> > >> diff --git a/cfg.mk b/cfg.mk > >> index bbfd4a2..92966d5 100644 > >> --- a/cfg.mk > >> +++ b/cfg.mk > >> @@ -699,7 +699,7 @@ ifeq (0,$(MAKELEVEL)) > >>test "$$stamp" = "$$actual"; echo $$?) > >>_clean_requested = $(filter %clean,$(MAKECMDGOALS)) > >>ifeq (1,$(_update_required)$(_clean_requested)) > >> -$(info INFO: gnulib update required; running ./autogen.sh first) > >> +$(error ERR: gnulib update required; running ./autogen.sh first) > > > > However, this is not the right fix - it will error out even when .gnulib > > is not dirty, but just out of date. I'll spend some time on this > > getting it right today. > > Thanks again for forcing me to fix this; if you hadn't noticed, it was > fixed here: > > https://www.redhat.com/archives/libvir-list/2012-October/msg00018.html > Good! pretty complex fix-up. -- liguanglig.f...@cn.fujitsu.com FNST linux kernel team -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [re-send][PATCH 1/3] add qemu driver hook
在 2012-10-08一的 20:05 -0600，Eric Blake写道： > On 10/08/2012 07:51 PM, liguang wrote: > > this hook aimed at migration only, it supposed > > to be used as a helper of migrate --copy-storage-* > > features to remove the unreasonable limitation > > of pre-exist disk images at migration target. > > someone can add more functions to hook files. > > NACK. Instead of writing a hook that runs outside of libvirt and has to > be installed to be of use, we should instead fix libvirt to do the file > creation itself. That is, you should be patching > src/qemu/qemu_migration.c to detect when copy-storage-* has been passed, really? sorry, I don't know any implicit libvirt development rules, but, as I see, there are none hooks used by libvirt until now, why don't we use them instead of just design and obsolete? can't hooks be installed just like other libvirt files? then, create files by python or c have difference? > and to then pre-create the proper empty files and give them correct > SELinux labels. > -- liguanglig.f...@cn.fujitsu.com FNST linux kernel team -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [re-send][PATCH 2/3] use WIFEXITED macro to see exit status of child
在 2012-10-08一的 20:05 -0600，Eric Blake写道：
> On 10/08/2012 07:51 PM, liguang wrote:
> > this usage was suggested by man-page of waitpid,
> > returns true if the child terminated normally
>
> NACK. virCommandRun already did this for you.
right, but not exactly,
virCommandRun will leave raw exit-status out of there,
so if the waited-command exit with a code '1',
then the caller of virCommandRun will see exit-status
value 0x100, and report an odd '256' exit-status.
obviously, the low byte has no meaning.
originally I think I should not handle this exit-status,
so I use WIFEXITED, if I have to take care of it,
at least the low byte should be ignored and report a
correct exit-status value '1'
>
> >
> > Signed-off-by: liguang
> > ---
> > src/util/hooks.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/src/util/hooks.c b/src/util/hooks.c
> > index f5890d2..55b98ca 100644
> > --- a/src/util/hooks.c
> > +++ b/src/util/hooks.c
> > @@ -280,7 +280,7 @@ virHookCall(int driver,
> > virCommandSetOutputBuffer(cmd, output);
> >
> > ret = virCommandRun(cmd, &exitstatus);
> > -if (ret == 0 && exitstatus != 0) {
> > +if (ret == 0 && WIFEXITED(exitstatus) == 0) {
> > virReportError(VIR_ERR_HOOK_SCRIPT_FAILED,
> > _("Hook script %s %s failed with error code %d"),
> > path, drvstr, exitstatus);
> >
>
--
liguanglig.f...@cn.fujitsu.com
FNST linux kernel team
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [re-send][PATCH v9] support offline migration
ping ...
在 2012-09-28五的 11:48 +0800，liguang写道：
> original migration did not aware of offline case,
> so, try to support offline migration quietly
> (did not disturb original migration) by pass
> VIR_MIGRATE_OFFLINE flag to migration APIs if only
> the domain is really inactive, and
> migration process will not puzzled by domain
> offline and exit unexpectedly.
> these changes did not take care of disk images the
> domain required, for them could be transferred by
> other APIs as suggested, then VIR_MIGRATE_OFFLINE
> should not combined with VIR_MIGRATE_NON_SHARED_*.
> so, this migration result is just make domain
> definition alive at target side.
>
> Signed-off-by: liguang
> ---
> include/libvirt/libvirt.h.in |1 +
> src/qemu/qemu_driver.c | 15
> src/qemu/qemu_migration.c| 53 -
> src/qemu/qemu_migration.h|3 +-
> tools/virsh-domain.c |6
> 5 files changed, 70 insertions(+), 8 deletions(-)
>
> diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
> index 79c7689..627e9d4 100644
> --- a/include/libvirt/libvirt.h.in
> +++ b/include/libvirt/libvirt.h.in
> @@ -995,6 +995,7 @@ typedef enum {
> * whole migration process;
> this will be used automatically
> * when supported */
> VIR_MIGRATE_UNSAFE= (1 << 9), /* force migration even if it
> is considered unsafe */
> +VIR_MIGRATE_OFFLINE = (1 << 10), /* offline migrate */
> } virDomainMigrateFlags;
>
> /* Domain migration. */
> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> index 6848924..105febf 100644
> --- a/src/qemu/qemu_driver.c
> +++ b/src/qemu/qemu_driver.c
> @@ -9631,6 +9631,15 @@ qemuDomainMigrateBegin3(virDomainPtr domain,
> }
>
> if (!virDomainObjIsActive(vm)) {
> +if (flags & VIR_MIGRATE_OFFLINE) {
> +if (flags & (VIR_MIGRATE_NON_SHARED_DISK|
> + VIR_MIGRATE_NON_SHARED_INC)) {
> +virReportError(VIR_ERR_OPERATION_INVALID,
> + "%s", _("migrating storage handled by volume
> APIs"));
> +goto endjob;
> +}
> +goto offline;
> +}
> virReportError(VIR_ERR_OPERATION_INVALID,
> "%s", _("domain is not running"));
> goto endjob;
> @@ -9643,6 +9652,7 @@ qemuDomainMigrateBegin3(virDomainPtr domain,
> if (qemuDomainCheckEjectableMedia(driver, vm, asyncJob) < 0)
> goto endjob;
>
> +offline:
> if (!(xml = qemuMigrationBegin(driver, vm, xmlin, dname,
> cookieout, cookieoutlen,
> flags)))
> @@ -9878,6 +9888,11 @@ qemuDomainMigrateConfirm3(virDomainPtr domain,
> goto cleanup;
> }
>
> +if (flags & VIR_MIGRATE_OFFLINE) {
> +ret = 0;
> +goto cleanup;
> +}
> +
> if (!qemuMigrationJobIsActive(vm, QEMU_ASYNC_JOB_MIGRATION_OUT))
> goto cleanup;
>
> diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> index 8e85875..411a4c2 100644
> --- a/src/qemu/qemu_migration.c
> +++ b/src/qemu/qemu_migration.c
> @@ -70,6 +70,7 @@ enum qemuMigrationCookieFlags {
> QEMU_MIGRATION_COOKIE_FLAG_GRAPHICS,
> QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE,
> QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT,
> +QEMU_MIGRATION_COOKIE_FLAG_OFFLINE,
>
> QEMU_MIGRATION_COOKIE_FLAG_LAST
> };
> @@ -77,12 +78,13 @@ enum qemuMigrationCookieFlags {
> VIR_ENUM_DECL(qemuMigrationCookieFlag);
> VIR_ENUM_IMPL(qemuMigrationCookieFlag,
>QEMU_MIGRATION_COOKIE_FLAG_LAST,
> - "graphics", "lockstate", "persistent");
> + "graphics", "lockstate", "persistent", "offline");
>
> enum qemuMigrationCookieFeatures {
> QEMU_MIGRATION_COOKIE_GRAPHICS = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_GRAPHICS),
> QEMU_MIGRATION_COOKIE_LOCKSTATE = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE),
> QEMU_MIGRATION_COOKIE_PERSISTENT = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT),
> +QEMU_MIGRATION_COOKIE_OFFLINE = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_OFFLINE),
> };
>
> typedef struct _qemuMigrationCookieGraphics qemuMigrationCookieGraphics;
> @@ -439,6 +441,9 @@ qemuMigrationCookieXMLFormat(struct qemud_driver *driver,
> virBufferAdjustIndent(buf, -2);
> }
>
> +if (mig->flags & QEMU_MIGRATION_COOKIE_OFFLINE)
> +virBufferAsprintf(buf, " \n");
> +
> virBufferAddLit(buf, "\n");
> return 0;
> }
> @@ -662,6 +667,11 @@ qemuMigrationCookieXMLParse(qemuMigrationCookiePtr mig,
> VIR_FREE(nodes);
> }
>
> +if ((flags & QEMU_MIGRATION_COOKIE_OFFLINE)) {
> +if (virXPathBoolean("count(./offline) > 0", ctxt))
> +mig->flags |= QEMU_MIGRATION_COOKIE_OFFLINE;
> +}
> +
> return 0;
>
>
Re: [libvirt] [PATCH 0/3] non-shared migration without target disk images
sorry, just an unnecessary re-sent, ignore it please 在 2012-09-28五的 11:48 +0800，liguang写道： > by now, if you want a non-shared migration, you have > to create same files at target as source side, which > seems intorlerable! > > this issue was reported by Reinier Schoof > http://www.redhat.com/archives/libvir-list/2011-December/msg00451.html > > These patches try to let migrate --copy-storage-* > work without pre-exist disk image files at target side. > > we may also hope qemu to aware of this issue > > hooks/qemu | 55 > ++ > src/Makefile.am |3 ++ > src/util/hooks.c |2 +- > 3 files changed, 59 insertions(+), 1 deletions(-) > -- liguanglig.f...@cn.fujitsu.com FNST linux kernel team -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v9] fix-up an implicit build dead-loop in cfg.mk
sorry, wrong prefix, re-sent it. 在 2012-09-28五的 11:48 +0800，liguang写道： > if gnulib submodule happened to be dirty, build > process will fall into '_autogen' target trap > in cfg.mk recursively, so break this dead-loop. > > Signed-off-by: liguang > --- > cfg.mk |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/cfg.mk b/cfg.mk > index bbfd4a2..92966d5 100644 > --- a/cfg.mk > +++ b/cfg.mk > @@ -699,7 +699,7 @@ ifeq (0,$(MAKELEVEL)) >test "$$stamp" = "$$actual"; echo $$?) >_clean_requested = $(filter %clean,$(MAKECMDGOALS)) >ifeq (1,$(_update_required)$(_clean_requested)) > -$(info INFO: gnulib update required; running ./autogen.sh first) > +$(error ERR: gnulib update required; running ./autogen.sh first) > Makefile: _autogen >endif > endif -- liguanglig.f...@cn.fujitsu.com FNST linux kernel team -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v9] support offline migration
ping ...
在 2012-09-25二的 15:45 +0800，liguang写道：
> original migration did not aware of offline case,
> so, try to support offline migration quietly
> (did not disturb original migration) by pass
> VIR_MIGRATE_OFFLINE flag to migration APIs if only
> the domain is really inactive, and
> migration process will not puzzled by domain
> offline and exit unexpectedly.
> these changes did not take care of disk images the
> domain required, for them could be transferred by
> other APIs as suggested, then VIR_MIGRATE_OFFLINE
> should not combined with VIR_MIGRATE_NON_SHARED_*.
> so, this migration result is just make domain
> definition alive at target side.
>
> Signed-off-by: liguang
> ---
> include/libvirt/libvirt.h.in |1 +
> src/qemu/qemu_driver.c | 15
> src/qemu/qemu_migration.c| 53 -
> src/qemu/qemu_migration.h|3 +-
> tools/virsh-domain.c |6
> 5 files changed, 70 insertions(+), 8 deletions(-)
>
> diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
> index 79c7689..627e9d4 100644
> --- a/include/libvirt/libvirt.h.in
> +++ b/include/libvirt/libvirt.h.in
> @@ -995,6 +995,7 @@ typedef enum {
> * whole migration process;
> this will be used automatically
> * when supported */
> VIR_MIGRATE_UNSAFE= (1 << 9), /* force migration even if it
> is considered unsafe */
> +VIR_MIGRATE_OFFLINE = (1 << 10), /* offline migrate */
> } virDomainMigrateFlags;
>
> /* Domain migration. */
> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> index 6848924..105febf 100644
> --- a/src/qemu/qemu_driver.c
> +++ b/src/qemu/qemu_driver.c
> @@ -9631,6 +9631,15 @@ qemuDomainMigrateBegin3(virDomainPtr domain,
> }
>
> if (!virDomainObjIsActive(vm)) {
> +if (flags & VIR_MIGRATE_OFFLINE) {
> +if (flags & (VIR_MIGRATE_NON_SHARED_DISK|
> + VIR_MIGRATE_NON_SHARED_INC)) {
> +virReportError(VIR_ERR_OPERATION_INVALID,
> + "%s", _("migrating storage handled by volume
> APIs"));
> +goto endjob;
> +}
> +goto offline;
> +}
> virReportError(VIR_ERR_OPERATION_INVALID,
> "%s", _("domain is not running"));
> goto endjob;
> @@ -9643,6 +9652,7 @@ qemuDomainMigrateBegin3(virDomainPtr domain,
> if (qemuDomainCheckEjectableMedia(driver, vm, asyncJob) < 0)
> goto endjob;
>
> +offline:
> if (!(xml = qemuMigrationBegin(driver, vm, xmlin, dname,
> cookieout, cookieoutlen,
> flags)))
> @@ -9878,6 +9888,11 @@ qemuDomainMigrateConfirm3(virDomainPtr domain,
> goto cleanup;
> }
>
> +if (flags & VIR_MIGRATE_OFFLINE) {
> +ret = 0;
> +goto cleanup;
> +}
> +
> if (!qemuMigrationJobIsActive(vm, QEMU_ASYNC_JOB_MIGRATION_OUT))
> goto cleanup;
>
> diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> index 8e85875..411a4c2 100644
> --- a/src/qemu/qemu_migration.c
> +++ b/src/qemu/qemu_migration.c
> @@ -70,6 +70,7 @@ enum qemuMigrationCookieFlags {
> QEMU_MIGRATION_COOKIE_FLAG_GRAPHICS,
> QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE,
> QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT,
> +QEMU_MIGRATION_COOKIE_FLAG_OFFLINE,
>
> QEMU_MIGRATION_COOKIE_FLAG_LAST
> };
> @@ -77,12 +78,13 @@ enum qemuMigrationCookieFlags {
> VIR_ENUM_DECL(qemuMigrationCookieFlag);
> VIR_ENUM_IMPL(qemuMigrationCookieFlag,
>QEMU_MIGRATION_COOKIE_FLAG_LAST,
> - "graphics", "lockstate", "persistent");
> + "graphics", "lockstate", "persistent", "offline");
>
> enum qemuMigrationCookieFeatures {
> QEMU_MIGRATION_COOKIE_GRAPHICS = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_GRAPHICS),
> QEMU_MIGRATION_COOKIE_LOCKSTATE = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_LOCKSTATE),
> QEMU_MIGRATION_COOKIE_PERSISTENT = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_PERSISTENT),
> +QEMU_MIGRATION_COOKIE_OFFLINE = (1 <<
> QEMU_MIGRATION_COOKIE_FLAG_OFFLINE),
> };
>
> typedef struct _qemuMigrationCookieGraphics qemuMigrationCookieGraphics;
> @@ -439,6 +441,9 @@ qemuMigrationCookieXMLFormat(struct qemud_driver *driver,
> virBufferAdjustIndent(buf, -2);
> }
>
> +if (mig->flags & QEMU_MIGRATION_COOKIE_OFFLINE)
> +virBufferAsprintf(buf, " \n");
> +
> virBufferAddLit(buf, "\n");
> return 0;
> }
> @@ -662,6 +667,11 @@ qemuMigrationCookieXMLParse(qemuMigrationCookiePtr mig,
> VIR_FREE(nodes);
> }
>
> +if ((flags & QEMU_MIGRATION_COOKIE_OFFLINE)) {
> +if (virXPathBoolean("count(./offline) > 0", ctxt))
> +mig->flags |= QEMU_MIGRATION_COOKIE_OFFLINE;
> +}
> +
> return 0;
>
>
Re: [libvirt] [PATCH v8][re-send] support offline migration
在 2012-09-21五的 11:50 +0100，Daniel P. Berrange写道： > # virsh -c avocado dominfo vm1 > Id: - > Name: vm1 > UUID: c7b3edbd-edaf-9455-926a-d65c16db1800 > OS Type:hvm > State: shut off > CPU(s): 1 > Max memory: 219200 kB > Used memory:219136 kB > Persistent: yes > Autostart: disable > Managed save: no - > Security model: selinux - I did not test security model, sorry for that. > Security DOI: 0 > > > So a normal migrate fails, which is good. > > # virsh -c avocado migrate vm1 mustard > error: Requested operation is not valid: domain is not running > > > > Now I try your new offline migrate, which claims to succeed > > # virsh -c avocado migrate --offline vm1 mustard did this operations succeed? if not, maybe there's something wrong with target mustard. for me, after update libvirt at both source and target virsh migrate --offline vm1 qemu+ssh://target/system always be OK. > > We should have rejected an attempt to use --offline, unless the user > has also specified either --persistent, or --copy-storage-all > > > > Regards, > Daniel -- liguanglig.f...@cn.fujitsu.com FNST linux kernel team -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
