* Dimitris Aragiorgis <[email protected]> [2013-05-25 12:06:51 +0300]: > > > > > > > > How do we guarantee that no two devices will have the same name? We > > > should > > > > double check this, to be sure there are no conflicts. > > > > > > > > > > > > > > Well we actually don't. Trimming system's generated uuid rises our chances > > > for duplicate IDs. If there is a way to generate a uuid of max 32 chars > > > starting with a letter based on the uuids of type > > > /proc/sys/kernel/random/uuid > > > then it would be great. Until we find one, we could disable hotplug for > > > devices > > > that have the uuid prefix. > > > > > > > That's going to be a problem, as it will generate errors for no reason. > > (sorry, you can't hotplug your device, because you were unlucky in the uuid > > roulette. please try again being luckier) > > > > How about using some information that is specific to the instance and can't > > change? eg. > > > > x<pci-id>_<start-of-uuid> > > or > > Well it seems that if we obtain the device pci slot before naming it then we > could definitely use it as an identifier. To this end, UUIDs are not a prereq. > And it seems to be doable. Good point. >
Well after second thoughts and code digging, I think the device naming should derive from uuid only. That is because when we remove a device via an rpc the object that is passed to the hypervisor does not have any pci details (because master is unaware of hypervisor specific info). It must be a deterministic way to produce a unique name that remains unchanged (the uuid, for example, does not change during device life)... > > x<arbitrary-integer>_<start-of-uuid> (where the arbitrary integer is just > > used for deduplication) > > > > Arbitrary integer cannot be used because device name should be anytime reproduce-able. > > OK. Sasha's feedback is more than helpful. I'll try to address the issues that > are raised, but still I think that those could extend the initial > implementation > discussed here and do not affect the basic design. > > > To sum up: > > 1) pci slot of each device must be saved in backend for the sake of > migrations. Should this be a slot in NIC, Disk objects or should it be > saved as a tupple in serialized data? > > 2) if we want disk hotplug, the format of runtime files should change. > block_devices > should be treated separately, just like NICs. Migrating old instances without > first > rebooting them still remains an issue. > > 3) merge all rpc calls in one hotplug_device(device, action) > > 4) do not include disk resizing in first implementation. > > 5) add hv param for enabling hotplug or not > > 6) warnings in case of disk/nic live removal > > 7) warnings in case hotplug is not supported but --hotplug option is passed > > 8) address Sasha's concerns: > * Parse kvm help output to see if hotplug is supported. > * Dig into the case where an instance does not run as a root. > > 9) address the uuid(or something)-to-kvm_device_name deterministic function. > Please let me know if I miss something. > > Thanks a lot for the discussion, > dimara dimara
signature.asc
Description: Digital signature
