This is almost certainly RTFM territory, so I ask at my own peril. Just be assured that repeated days of googling hasn't told me what I want to know.
Quick background: I'm looking to use OpenStack Nova (Essex, Ubuntu 12.04 packages, 64-bit) to build a large pool of persistent KVM VMs, though used on-demand -- that is, not necessarily always on. These VMs could then be used to augment existing physical server pools during high resource usage. I need to have *really* fixed IPs, i.e. the IP on the vm will be registered with DNS and should be on that same VM forever. To get things working with our imaging system, the VM also needs to have a specific MAC address (at least the first time it runs), so the imaging system's DHCP+PXE can recognize the new node and image accordingly. I'm subclassing FlatManager to manage the MAC address (it's taking the IP passed in with "nova boot ... --nic=" and converting the last 3 octets into the last 3 octets of the MAC address -- ugly, not very portable, but works for now), since this all needs to live in existing networks. It's entirely possible what I'm trying to do just isn't a good fit for Nova, but it already takes care of a lot of other things for me (like volume mgmt, etc) that I'd otherwise have to solve myself. If it isn't a good fit, if anyone has any alternative suggestions for projects I should look at, I'd definitely appreciate it! * What is the right way to stop/start a persistent instance? So far I've been using 'nova boot' to start and 'nova delete' to stop. E.g.: > nova boot --flavor=1 --image c5cecc17-295c-4ebc-9019-2ccc222d3f52 > --key_name=key3 --nic > net-id=63743ee0-f8a1-45f8-888a-cce38d09cca2,v4-fixed-ip=192.168.1.2 > --block_device_mapping vda=11 --block_device_mapping vdb=12 > --nic=net-id=63743ee0-f8a1-45f8-888a-cce38d09cca2 myvm1 > nova delete myvm1 This has the drawbacks that subsequent uses of 'nova boot' for that VM want to recreate all the various entries in the various tables, so if I call 'nova boot' again, the 'virtual_interface' table still has an entry in it with that MAC address, so the startup will fail unless I delete that entry (MAC field is unique). And 'fixed_ips' for subsequent startups will grab a different IP address, unless I update that entry in 'fixed_ips' and set instance_id=NULL. That is, doing a 'nova delete' doesn't change anything in the mysql entries for that instance's 'fixed_ips' or 'virtual_interfaces'. Or should 'nova delete' actually be doing those things (like setting the virtual_interfaces entry's 'deleted' to 1 or setting instance_id to NULL) and I've just broken them? :) So I'm hoping/guessing that there's a smarter way to do this that tells Nova that it can start up a shut-off instance, instead of a fresh one, in which case it'd presumably pick up its old entries in virtual_interfaces/fixed_ips. Though then I suppose there'd have to be a way to boot with something like "nova boot ... --instance=## ...". For powering on/off, 'nova host-action' looked promising, but hasn't been implemented yet for libvirt. * Not really a question, but if I'm using persistent storage, it'd be nice if I didn't have to specify "--image", since I'm not actually using the image. * Is there a way to add an interface, but without Nova trying to configure it? That is, add an eth1 to the vm but do nothing else (yes, I realize I'll have to muck with ebtables/iptables on the compute node). Our imaging process will take care of the network configuration, so it'd be one less thing to add to Nova's management overhead. I can probably accomplish the same thing with a dummy network on the VM's eth1, since it's not actually being injected. * Any plans to add a mac= subarg to the "--nic" option in 'nova boot'? * Anybody else using Nova like this, esp on existing networks? Sorry for the long and rambling email! _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
