From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bader Subject: Re: [libvirt] Setting devid for emulated NICs (Xen 4.3.1 / libvirt 1.2.0) using libxl driver Date: Fri, 20 Dec 2013 11:16:38 +0100 Message-ID: <52B41906.7010506__31825.300717219$1387534713$gmane$org@canonical.com> References: <52B07D09.5060008@canonical.com> <1387299534.1025.19.camel@dagon.hellion.org.uk> <52B08AA9.8010809@canonical.com> <1387369646.27441.129.camel@kazak.uk.xensource.com> <52B19F4E.8010601@canonical.com> <1387373284.28680.18.camel@kazak.uk.xensource.com> <52B1B842.4090306@canonical.com> <52B2415A.3030903@suse.com> <1387448340.9925.30.camel@kazak.uk.xensource.com> <52B3278D.3000607@canonical.com> <1387475839.17289.20.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6350489432099100460==" Return-path: In-Reply-To: <1387475839.17289.20.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: libvir-list@redhat.com, Jim Fehlig , Xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============6350489432099100460== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dCS3dl0Nt4g5MNTwwVjWfjMTSR9t7XgUh" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dCS3dl0Nt4g5MNTwwVjWfjMTSR9t7XgUh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 19.12.2013 18:57, Ian Campbell wrote: > On Thu, 2013-12-19 at 18:06 +0100, Stefan Bader wrote: >>> How about we: >>> * move the init to setdefault to catch the single NIC added via= >>> hotplug case >> >> Init of devid? >=20 > Yes, sorry for not being clear. >=20 >> Hm, would that work as I am not sure there is a simple way of >> differentiating between a NIC config for a single hotplug and one that= is part >> of a create-time array... >=20 > The create time array would be initialised with devid's !=3D -1 as part= of > the steps outlined in the following bullets, so setdefault woudln't > touch it again. >=20 >> >>> * we add somewhere early in the domain create path a call to a >>> function which assigns devids to an entire array of devices (= and >>> do it for all the different device types). Perhaps in >>> initiate_domain_create() after the calls to >>> libxl__domain_create_info_setdefault and >>> libxl__domain_build_info_setdefault but before the loop calli= ng >>> libxl__device_disk_setdefault for the disks. >>> * perhaps that same function should call setdefault too, after >>> having assigned the device, rather than it being done later i= n >>> an adhoc way? >>> >>> Does that sound at all plausible? >> >> I wonder, well this won't help for any other device types (maybe not r= eally >> needed), what about just adding the following to the existing loop in >> domcreate_launch_dm (just a brain dump, not even tried to compile): >> >> for (i =3D 0; i < d_config->num_nics; i++) { >> /* We have to init the nic here, because we still haven't >> * called libxl_device_nic_add at this point, but qemu needs >> * the nic information to be complete. >> */ >> ret =3D libxl__device_nic_setdefault(gc, &d_config->nics[i], d= omid); >> if (ret) >> goto error_out; >> + if (d_config->nics[i].devid < 0) >> + d_config->nics[i].devid =3D i; >> } >> >> Of course this a gain won't work well if the caller had assigned some = devids but >> not other. >=20 > Indeed. >=20 >> Ok, maybe do the loop twice, first round sets default and picks the >> highest pre-assigned devid and second round makes sure any still unass= igned ones >> are set to ++that. >=20 > That would potentially leave holes, I don't know if that matters.=20 Yeah, probably rather rare. This just sounded like a less intrusive chang= e which would only address the problem that no devid is no option when starting t= he dm. >=20 >> Oh, just while talking about setdefault. Jim, this is one of the odd t= hings when >> moving from xm to xl stack from libvirt: libvirt defaults to the netfr= ont NIC >> when no model is specified and sets the type. The libxl setdefault fun= ction sets >> the model to rtl8139 but leaves the type untouched. >=20 > This sounds like a bug in libxl to me -- it should do something > consistent I think. >=20 >> So setting no model in the >> xml config creates a domain with no emulated NIC (this does not matter= after >> Linux is up because the emulated devices get unplugged). Just that PXE= boot will >> not work. This gets odd because with the old xen (xm) driver, no model= meant >> rtl8139. >> >> Sigh, and to hijack this thread even further I noticed a quite unexpec= ted >> behaviour when starting a domain trhough libvirt and then try to use "= xl list >> -l" to get config details. "xl list" shows all running domains but "xl= list -l" >> produces something like "you have to specify a domain name". I found t= he origin >> of this to be libxl_userdata_retrieve which takes a userdate_userid as= an >> argument. Libvirt uses "libvirt-xml" for that, while xl uses "xl". Thi= s might be >> intentional and the bug is just that we need a better check for not fi= nding the >> userdata and then skipping those domains. On the other hand ... its af= ter all in >> both cases a domain created and started through libxl... >=20 > I think this was discussed a few weeks ago on the list, and there were > one or two separate bugs and short comings. I'm not sure which subset > were actually fixed. >=20 > One issue is that xl stored the guest config and then retrieves it for > use in xl list -l, but libvirt !=3D xl and therefore has no config file= to > save. Right, that kind of was what I tried to say in many words. :) Oh, hm prob= ably with the addition that xl would save configs with one key and libvirt wit= h another. So relying on that at least results in xl not being able to show= details of libvirt created domains (and the other way round). But as you said, I seem to have missed some discussion about it (which I = saw Jim mentioning a link but have not followed, yet, this morning. >=20 > The solution is probably for the list stuff to be based on dynamically > gathering the domain info, instead of reparsing the config. Yes, that sounds good. It would feel like a more intuitive behavior to me= (not that I think I could call myself an expert on "intuitivity"). >=20 > Ian., >=20 >=20 --dCS3dl0Nt4g5MNTwwVjWfjMTSR9t7XgUh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJStBkPAAoJEOhnXe7L7s6jYIUQALbl1vufZIj0cca/7tizU4tV DOV6LVhN6p34N8h9K600IvB0a2sH53YJaUFTuPA4x/GIeDTqOTflvHbTnxBNXFk6 iOAZlFhQo+bVK7A3ePIra8CJuJnj58yngo12RQt9QNucMRFsmSrqg1PZHAjpA3xf 3aOGOxeFxIBFPnv48CclxtYLD5kQTKyODvnRNYdOEsHJeqajzf7IHaoTpi4dL0Zv LADo3lN+8u53c6nmkCMlOrUTHmk6zuAiTWx3UQizu0Gd6skf5jA5xrxymZVScJKa IkkEFZ1w2DXpH+na6OdVQvk3q9Pn+y9Dff/xC0dpUnm/+ieVDS0910UUpwsM4LDJ yYZdy/P1PDbGhUOICXQPfUReJAhfCSpPTmyIfSnpNTrCtr2acQasAKRh5V4As55h PN6MtQRMhqsfJdnk/orIhC3ESUSw6zKUMzCiuWPfU0GhOjF11322Zo8Kp0VHFaxm ede3E9IS2G4cS9Ws9BE6Z59y3rODDB/UuThIQ7EUhEw7ln5RqsoeDEF28IjUzHVG cHP9Z2x5aL+5Kj16hgnVlLekpYtlwAPAlT4KN0NhlIvxgSyexTBE0d4bCL77SvUg E6v0xO20cunCox7J0fHo5Vrk/Z9Ui+MuE9j5ihUSUWoRxQPQZAdX+P5V53MOlF7p mmurmdPfK170yedwmfwN =hIVj -----END PGP SIGNATURE----- --dCS3dl0Nt4g5MNTwwVjWfjMTSR9t7XgUh-- --===============6350489432099100460== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6350489432099100460==--