moseleymark at gmail
May 3, 2012, 4:50 PM
Post #1 of 3
This is almost certainly RTFM territory, so I ask at my own peril.
Questions on VM Lifecycle
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
* 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 [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp